Diskussion zu: Das Speicherinterface der GeForce GTX 970 erreicht nirgendwann ...

[Leonidas]

Link zur News:
http://www.3dcenter.org/news/das-speicherinterface-der-geforce-gtx-970-erreicht-nirgendwann-mehr-als-224-bit-ddr

[captain_drink]

Bei PCper wurde behauptet, dass die 970 durchaus beide Bereiche gleichzeitig ansprechen kann:
I wanted to clarify a point on the GTX 970's ability to access both the 3.5GB and 0.5GB pools of data at the same. Despite some other outlets reporting that the GPU cannot do that, Alben confirmed to me that because the L2 has multiple request busses, the 7th L2 can indeed access both memories that are attached to it at the same time.

Zudem heißt es, die 224 GB/s des 256-Bit-SI würden bei Zugriff auf beide Pools erreicht.

http://www.pcper.com/reviews/Graphics-Cards/NVIDIA-Discloses-Full-Memory-Structure-and-Limitations-GTX-970

Was stimmt denn nun?

[OBrian]

Dann würde der letzte halbe GB zwar gecacht vom L2 des Blocks davor (also 3,0 bis 3,5 GB), aber dann müßte der ja auch ausgebremst werden, weil ja nun doppelt so viel RAM an diesem Cache hängt, er also überlastet wird. Würde aber zumindest einen extrem harten Abfall abmildern.

Das müßte sich durch genau zugeschnittene synthetische Benchmarks (sprich mit einstellbarer Speicherbelegung) aber klären lassen.

[Freed]

Das mit den 224 bit ist keine Neuigkeit, stand schon in der Analyse bei Anandtech und hab ich damals auch angesprochen, aber ist nie jmd drauf eingegangen.

http://www.anandtech.com/show/8935/geforce-gtx-970-correcting-the-specs-exploring-memory-allocation/2

"Ultimately due to the design of the crossbars and the memory controllers, it is not possible for 1 crossbar port to carry the full load of 2 memory channels in all circumstances. The crossbar port and its attached ROP/L2 unit can access both memory channels at once, splitting up the 4 operations among them, but there is only 1 read return bus and 1 write data bas, and hence in practice it cannot issue identical operations to both memory channels at once"

und

"Unfortunately what this means is that accessing the weaker 512MB segment blocks access to the stronger 3.5GB segment if both memory operations are identical; or put another way, using the 512MB segment can harm the performance of the 3.5GB segment. For example, if we want to issue reads to both segments at once, reading the 512MB segment blocks any other reads to the 3.5GB segment for that cycle"

[z3ck3]

Für mich ist immer noch nicht klar warum NVidia nicht schlicht eine 3.5GB Karte mit entsprechendem Cache und Speicherinterface raus gebracht hat, statt dieses seltsame Etwas. Das kann ja nur Marketingsgründe haben um auf dem Papier etwas vorzuteuschen, was es in der Realität so nie bringt. Und das währe dann für mich ein Grund mein Geld zurück zu fordern und ein Produkt der Konkurenz zu kaufen, allein um meinen Ärger über diese Firma zu kompensieren. Normalerweise finde ich NVidia in den meisten Bbereichen viel besser als AMD, sowohl im Bereich Hardware, als auch Software, doch mit der GTX 970 hat NV bei mir den Bock abgeschossen. Vermutlich werde ich mich beim nächsten Neukauf einmal ganz genau bei AMD umsehen. Die letzte AMD/ATI die ich persönlich besaß war die ATI 9600 Pro...

[Thunder99]

Eine weitere zielführende Bezeichnung wäre auch "256bit (effektiv 224bit)" anstatt "32/224bit"

[Gast]

Bei dem ganzen Theater wäre es wohl am besten, die sinnlosen 0,5gb einfach wieder abzubauen bzw gleich wegzulassen. Dann dürften die Probleme wohl auch gelöst sein.

[Leonidas]

Bei PCper wurde behauptet, dass die 970 durchaus beide Bereiche gleichzeitig ansprechen kann:


Zudem heißt es, die 224 GB/s des 256-Bit-SI würden bei Zugriff auf beide Pools erreicht.

http://www.pcper.com/reviews/Graphics-Cards/NVIDIA-Discloses-Full-Memory-Structure-and-Limitations-GTX-970

Was stimmt denn nun?



Das würde ich anders lesen. Hier ist eher gemeint, daß man durchaus Zugriff auf 4 GB hat. Auch für das gleiche Projekt, die gleiche Arbeit. Nur nicht zum gleichen Takt, das ist der Unterschied. 7 Takte schneller Speicherbereich, ein Takt langsamer Speicherbereich.

Ich bin zumindest mal der Erklärung von aths gefolgt, der klar sagt, daß ein Zugriff auf den 8. Speichercontoller den Zugriff auf die anderen Speichercontroller blockiert.

[OBrian]

daß ein Zugriff auf den 8. Speichercontoller den Zugriff auf die anderen Speichercontroller blockiert. sollte eigentlich nur den 7. blockieren, weil der ja bei der 970 eben doppelt mit RAM belegt ist.

Aber dann müßte die Geschwindigkeit bei Überschreiten der 3,5-GB-Grenze auf schlimmstenfalls die Hälfte runtergehen (also in dem Grenzfall, daß nur auf Daten aus Block 7 und 8 zugegriffen wird, also alles auf Controller Nummer 7), aber anscheinend geht es ja noch viel weiter runter, wenn es hart auf hart kommt. Und bei normal verteilten Zugriffen auf die ganzen 4 GB müßte die Geschwindigkeit bei 7/8 (also 87,5 %) eines richtigen 256-bit-SIs liegen, dem ist ja auch nicht so. Das könnten dann aber Treiberprobleme sein. Mal sehen, ob NV da noch was dran drehen kann.

Ändert natürlich nichts an dem Marketingbeschiß, der da versucht wurde. Aber wundern tut mich das nicht mehr.

[Spasstiger]

Die Berechnung der effektiven Bandbreite im Artikel passt nicht. Wenn permanent auf die vollen 4 GiB zugegriffen wird (nur lesen oder nur schreiben) gibt es gleichviele Zyklen mit 32-Bit-Zugriff wie Zyklen mit 224-Bit-Zugriff. D.h. die Hälfte der Zeit hat man 28 GB/s Banbreite und die andere Hälfte der Zeit 196 GB/s. Ergibt im Mittel 112 GB/s, also exakt die Hälfte der GTX 980. Das Verhalten in der Praxis zeigt aber, dass selbst dies nur eine Milchmädchenrechnung sein kann. Ich vermute, dass die Beschneidung des L2-Cache sich ebenfalls nachteilig auswirkt, weil die Speicherbereiche über 512 MiB nicht permanent abgebildet werden können. Die resultierend hohen Zugriffszeiten beim Zugriff auf diesen Speicherbereich führen dann wiederum zu einer zeitweisen Nicht-Auslastung der Rechenkerne.

[OBrian]

nein, die 980 hat 8 Speichercontroller mit 32 bit, die 970 nur 7, davon sechs genauso mit 32 bit und einen, an dem 2x 32 bit RAM hängen, der aber selber nicht stärker ist als die anderen, als überlastet ist. Wie gesagt müßte das eigentlich bedeuten, daß die ersten 6 genausoviel Bandbreite erzeugen wie bei der 980, der 7. aber eben nur halbe Geschwindigkeit hat. Also insgesamt 87,5 % einer 980 erreicht werden. Praktisch liegt aber der Wert viel niedriger, man fällt in so eine Art Turboloch, sobald 3,5 GB überschritten werden.

Letztlich sind das aber alles Milchmädchenrechnungen, weil wie keine Grundlage haben, auf der wir ernsthaft rechnen könnten, denn der Aufbau des Chips ist ja Firmengeheimnis, wir haben nur das, was Nvidia uns als Doku vorgesetzt hat, und das ist ziemlich dürftig. Alles darüber hinaus ist bestenfalls (wenn es von den richtigen Leuten kommt, also nicht solchen wie mir^^) fachlich fundierte Spekulation, aber eben auch nur geraten.

[Leonidas]

Ergibt im Mittel 112 GB/s, also exakt die Hälfte der GTX 980.


Passt IMO nicht. In die letzten 0,5 GB Speicher greift man ja sicher nur 1/8 der Zeit zu, es sind ja auch nur 1/8 des insgesamten Speicher.

[Steffko]

Bedeutet das nicht, dass die 970 schneller wäre, wenn die 0,5GB einfach deaktiviert wären? Dann könnte man doch im Fall, dass der Grafikspeicher (also die 3,5GB) voll ist, immerhin auf den Hauptspeicher zurückgreifen. Der wäre zwar grottig lahm (was wird die CPU bei dual Channel 1600er übrig lassen, 10-15GB/s?), aber dafür könnte man gleichzeitig (?) auf den Videospeicher mit vollem Tempo zugreifen.

[MrSpadge]

Leo, schau dir doch bitte mal den Beitrag von Freed an. Die dort zitierten Informationen stammen über Anandtech direkt von nVidia und sind somit erstmal jeglichen eigenen Spekulationen und Interpretationen der Skizzen von nvidia vorzuziehen.

Dort steht ganz klar, dass die GTX970 nicht auf allen Speichercontrollern zugleich lesen oder schreiben kann, ein Mischbetrieb geht jedoch. Ich hab mir das auch noch mal explizit von Ryan (der mit nVidia telefoniert hat) bestätigen lassen. Titel und Hauptaussage der Meldung "Das Speicherinterface der GeForce GTX 970 erreicht nirgendwann mehr als 224 Bit DDR " sind somit schlicht falsch. Ob das praktische Auswirkungen hat, d.h. ob ein Mischbetrieb jemals zur Geltung kommt, ist eine andere Frage.

Das wurde auch schon alles in der Diskussion zu deiner früheren Meldung "nVidia räumt das "3,5-GB-Problem" der GeForce GTX 970 ein" mehrmals gesagt. Dort hattest du es nur unbestimmt auf den fehlenden L2-Cache geschoben. Es ist klar, dass du gerade die Forenbeiträge zu dem Thema nicht alle im Auge behalten kannst - allerdings solltest du die heutige Meldung schnell nachbessern.

Ergibt im Mittel 112 GB/s, also exakt die Hälfte der GTX 980.
Passt IMO nicht. In die letzten 0,5 GB Speicher greift man ja sicher nur 1/8 der Zeit zu, es sind ja auch nur 1/8 des insgesamten Speicher.
Spasstiger hat Recht:

Die letzten 0.5 GB enthalten zwar nur 1/8 der Daten, dafür wird aber auch nur mit 1/8 der Speichercontroller zugegriffen und die Datenrate ist entsprechend geringer. Sollen z.B. 256 Bit gelesen werden, die gleichförmig über die gesamten 4 GB verteilt sind, so könnten die ersten 7 Speichercontroller 224 Bit in einem Takt lesen. Danach muss der 8. Controller die letzten 32 Bit in einem weiteren Takt lesen. Ist etwas vereinfacht, aber verdeutlicht gut, dass die Karte 1/2 der Zeit mit 224 Bit bzw. 196 GB/s liest und die andere Hälfte der Zeit mit 32 Bit bzw. 28 GB/s. Im Mittel sind das genau 112 GB/s.

@Steffko: 28 GB/s in den letzten 0.5 GB sind immernoch deutlich schneller als 16x PCIe 3 und Teilung der Bandbreite mit der CPU. Die PCIe-Zugriffe blockieren den VRAM zwar nicht, allerdings geift die Karte ja nicht grundlos auf diese Speicherbereiche zu - sondern weil sie irgendwas davon braucht. Und wenn sie darauf "ewig" warten muss, hilft das auch nicht. Deshalb brechen die fps auch so massiv ein, wenn der VRAM alle ist - ziemlich unabhängig davon, ob PCIe 1, 2 oder 3.. nutzbar ist das in keinem Fall. Und diese Möglichkeit hat die jetzige 4 GB GTX970 ja auch noch.

MrS

[sloth9]

...

Sollen z.B. 256 Bit gelesen werden, die gleichförmig über die gesamten 4 GB verteilt sind, so könnten die ersten 7 Speichercontroller 224 Bit in einem Takt lesen. Danach muss der 8. Controller die letzten 32 Bit in einem weiteren Takt lesen. Ist etwas vereinfacht, aber verdeutlicht gut, dass die Karte 1/2 der Zeit mit 224 Bit bzw. 196 GB/s liest und die andere Hälfte der Zeit mit 32 Bit bzw. 28 GB/s. Im Mittel sind das genau 112 GB/s.

...



Der Controller würde aber nie 256 Bit so über alle 8. Controller schreiben, das zum Lesen alle 8. benötigt würden, sondern bei Belastung unter 3,5 GByte VRAM nur mit 7.

[²Thom]

Man hätte beim Start der 970 schon hellhörig werden müssen.
Nvidia verkauft eine Karte, mit einem sehr guten Preis/Performance-Rating, --freiwillig.
Da mußte noch ein Perdefuss mit dran sein. ;-)

[Steffko]

@Steffko: 28 GB/s in den letzten 0.5 GB sind immernoch deutlich schneller als 16x PCIe 3 und Teilung der Bandbreite mit der CPU. Die PCIe-Zugriffe blockieren den VRAM zwar nicht, allerdings geift die Karte ja nicht grundlos auf diese Speicherbereiche zu - sondern weil sie irgendwas davon braucht. Und wenn sie darauf "ewig" warten muss, hilft das auch nicht. Deshalb brechen die fps auch so massiv ein, wenn der VRAM alle ist - ziemlich unabhängig davon, ob PCIe 1, 2 oder 3.. nutzbar ist das in keinem Fall. Und diese Möglichkeit hat die jetzige 4 GB GTX970 ja auch noch.

MrS


Das ist schon klar. Nur was passiert in dem Moment, in dem die Grafikkarte nicht nur auf den einen, sondern auch auf den anderen Block ständig zugreifen muss? Mir erscheint es dann eben so, dass im einen Fall (3,5GB Grafikkarte) zwar der ausgelagerte Teil sau lahm ist, aber dafür der nicht-ausgelagerte Teil dauerhaft sehr schnell. Im anderen (die reale GTX 970) dagegen wirds dann ständig hin und her gehen - mal wird auf den sehr schnellen 3,5GB Teil zugegriffen und alles ist super, mal wird auf den sehr lahmen 0,5GB Teil zugegriffen und es läuft praktisch gar nichts mehr, weil während diesem Zugriff der 3,5GB Teil komplett blockiert ist. So würde ich mir jetzt auch laienhaft das massive Stocken erklären, von dem User in gewissen Settings berichten?

[Gast]

Das mit den 224 bit ist keine Neuigkeit, stand schon in der Analyse bei Anandtech und hab ich damals auch angesprochen, aber ist nie jmd drauf eingegangen.

http://www.anandtech.com/show/8935/geforce-gtx-970-correcting-the-specs-exploring-memory-allocation/2

"Ultimately due to the design of the crossbars and the memory controllers, it is not possible for 1 crossbar port to carry the full load of 2 memory channels in all circumstances. The crossbar port and its attached ROP/L2 unit can access both memory channels at once, splitting up the 4 operations among them, but there is only 1 read return bus and 1 write data bas, and hence in practice it cannot issue identical operations to both memory channels at once"

und

"Unfortunately what this means is that accessing the weaker 512MB segment blocks access to the stronger 3.5GB segment if both memory operations are identical; or put another way, using the 512MB segment can harm the performance of the 3.5GB segment. For example, if we want to issue reads to both segments at once, reading the 512MB segment blocks any other reads to the 3.5GB segment for that cycle"

Wenn man eine Quelle angibt sollte man diese allerdings auch vollständig lesen.

Despite all of this, achieving peak memory bandwidth performance on the GTX 970 is still possible, but it requires much more effort since simple striping will not do the trick. The easiest and most effective solution in this regard is to interleave reads and writes over the segments, such that one segment is writing while another segment is reading. Interleaving in this fashion allows both segments to work at once – avoiding the blocking effect of the shared read and write buses – and makes it more likely that both segments are doing useful work rather than waiting for their turn on an operation.

Die volle Bandbreite kann also durchaus erreicht werden, allerdings nur wenn man in einem Segment liest und im anderen schreibt.

[Gast]

sollte eigentlich nur den 7. blockieren, weil der ja bei der 970 eben doppelt mit RAM belegt ist.

Das blockiert eben den gesamten Zugriff, da man zum lesen aus dem 3,5GiB Block ja immer Zugriff auf 7 Speicherchips parallel braucht, da die Daten ja auch auf 7 Chips parallel gespeichert werden.

[MrSpadge]

Dann kommt es darauf an, ob die ausgelagerten Daten in irgend einer Art und Weise gebraucht werden. D.h. bremst es die GPU aus, wenn diese Daten nur mühsam über den PCIe kommen? Wenn nicht, dann sollte dies in der Tat schneller sein als der 224 + 32 Bit Mischbetrieb.

Andererseits: wenn diese Daten nicht zeitkritisch benötigt werden, könnte man sie mitdestens genauso gut "bei Gelegenheit" in den oberen 0.5 GB ablegen. D.h. immer wenn in den ersten 3.5 GB gelesen wird, kann man "kostenlos" was in die oberen 0.5 GB auslagern. Und hat dann hoffentlich genug Zeit bis zum wieder einlesen, dass irgendwann auch mal in die ersten 3.5 GB geschrieben wird. (wobei ich keine Ahnung habe, in wie fern OS / API / Treiber / Engine solche feinen Optimierungen überhaupt zulassen würden)

MrS

[Birdman]

sollte eigentlich nur den 7. blockieren, weil der ja bei der 970 eben doppelt mit RAM belegt ist.
Da die Daten interleaved in den andern 7 Blöcken abgelegt sind, bringt es nichts wenn man zwar an diese Bits der ersten 6 rankommt, aber nicht an die im siebten.
Man braucht die Daten aus allen sieben Blöcken um damit weiterarbeiten zu können, daher kommt es quasi auf selbe raus ob man nun von den ersten sechs parallel lesen kann oder nicht.

[aths]

Bei PCper wurde behauptet, dass die 970 durchaus beide Bereiche gleichzeitig ansprechen kann:

Zudem heißt es, die 224 GB/s des 256-Bit-SI würden bei Zugriff auf beide Pools erreicht.

http://www.pcper.com/reviews/Graphics-Cards/NVIDIA-Discloses-Full-Memory-Structure-and-Limitations-GTX-970

Was stimmt denn nun?
"*To those wondering how peak bandwidth would remain at 224 GB/s despite the division of memory controllers on the GTX 970, Alben stated that it can reach that speed only when memory is being accessed in both pools."

Wir haben nur ein indirektes Zitat. Ist es Absicht, dass er sich nicht wörtlich zitieren lassen wollte?

Das Zitat ist zudem nicht falsch: "when memory is being accessed in both pools." Wenn, dann ja. Passiert nur nie.

Mit acht Memorycontrollern kann man den achten RAM-Chip zwar gleichzeitig ansprechen, aber wohin mit den Daten? Das Schaubild ist eindeutig: Der siebte L2-Baustein bedient zwei Speichercontroller. Wenn man aus dem 3,5-GB-Pool liest, gehen Daten aus dem siebten Speicherchip in den siebten L2-Cacheblock. Es sind keine zusätzlichen Datenpfade eingezeichnet um anzudeuten, dass ein Cacheblock doppelt so viele Daten (also aus zwei Speichercontrollern) pro Takt lesen könnte.

[Gast]

Mit acht Memorycontrollern kann man den achten RAM-Chip zwar gleichzeitig ansprechen, aber wohin mit den Daten? Das Schaubild ist eindeutig: Der siebte L2-Baustein bedient zwei Speichercontroller. Wenn man aus dem 3,5-GB-Pool liest, gehen Daten aus dem siebten Speicherchip in den siebten L2-Cacheblock. Es sind keine zusätzlichen Datenpfade eingezeichnet um anzudeuten, dass ein Cacheblock doppelt so viele Daten (also aus zwei Speichercontrollern) pro Takt lesen könnte.


Angeblich geht das schon.

I wanted to clarify a point on the GTX 970's ability to access both the 3.5GB and 0.5GB pools of data at the same. Despite some other outlets reporting that the GPU cannot do that, Alben confirmed to me that because the L2 has multiple request busses, the 7th L2 can indeed access both memories that are attached to it at the same time.

Man könnte durchaus es durchaus so interpretieren, dass dieses "buddy interface" parallelen Zugriff auf beide Speicher erlaubt.

[MrSpadge]

Aths, der Bus zwischen Speichercontrollern, L2/ROP und Crossbar ist bidirektional. Das ist nicht als zwei Linien mit Richtungspfeilen eingezeichnet, vermutlich um es einfach zu halten. Hat nvidia aber laut Ryan von Anadtech definitiv so gesagt. Möchtest du nen link dazu?

Damit ist ganz klar: du jast Recht in dem Sinne, dass nie gleichzeitig auf allen Controllern gelesen oder gleichzeitig auf allen geschrieben werden kann. Es stimmt aber nicht, dass sowas deshalb nie möglich wäre: wenn ein Block liest und der andere schreibt kann immernoch die maximale Bandbreite von 256 Bit/Takt erreicht werden.

MrS

[RLZ]

Man hätte beim Start der 970 schon hellhörig werden müssen.
Nvidia verkauft eine Karte, mit einem sehr guten Preis/Performance-Rating, --freiwillig.
Da mußte noch ein Perdefuss mit dran sein. ;-)
An dem Preis/Performance Verhältnis hat sich ja nichts geändert. Die gemachten Benchmarks sind nach wie vor ok. Ich sehe das eher als Marketing Gau und weniger als ein technisches Problem für die Nutzer.

Ich ärger mich viel mehr über die gemachten Versprechen zu den VR Features. Die haben offensichtlich weder existiert noch wurde daran entwickelt.

[Birdman]

wenn ein Block liest und der andere schreibt kann immernoch die maximale Bandbreite von 256 Bit/Takt erreicht werden.
Hui Achtung! Wenn diese Sicht der Dinge von nVidia wirklich als Argument für ein "GTX970 hat 256bit Memory Interface" gebracht wird, dann mache ich mir Sorgen, welche Quirks uns die VGA-Chip Hersteller in Zukunft als technische Merkmale verkaufen wollen.

Kommt mir vor wie die 800Hz Fernseher im MediaMarkt....

[aths]

Aths, der Bus zwischen Speichercontrollern, L2/ROP und Crossbar ist bidirektional. Das ist nicht als zwei Linien mit Richtungspfeilen eingezeichnet, vermutlich um es einfach zu halten. Hat nvidia aber laut Ryan von Anadtech definitiv so gesagt. Möchtest du nen link dazu?

Damit ist ganz klar: du jast Recht in dem Sinne, dass nie gleichzeitig auf allen Controllern gelesen oder gleichzeitig auf allen geschrieben werden kann. Es stimmt aber nicht, dass sowas deshalb nie möglich wäre: wenn ein Block liest und der andere schreibt kann immernoch die maximale Bandbreite von 256 Bit/Takt erreicht werden.

MrS
Solche Angaben sind ohne echte Details sogut wie wertlos. Aus einem bidirektionalem Bus ohne nähere Angaben folgt nicht, dass der L2-Cacheblock gleichzeitig Lese- und Schreib-Transaktionen mit jeweils voller Bandbreite vornehmen kann.

[Gast]

Dann kommt es darauf an, ob die ausgelagerten Daten in irgend einer Art und Weise gebraucht werden. D.h. bremst es die GPU aus, wenn diese Daten nur mühsam über den PCIe kommen? Wenn nicht, dann sollte dies in der Tat schneller sein als der 224 + 32 Bit Mischbetrieb.

Andererseits: wenn diese Daten nicht zeitkritisch benötigt werden, könnte man sie mitdestens genauso gut "bei Gelegenheit" in den oberen 0.5 GB ablegen. D.h. immer wenn in den ersten 3.5 GB gelesen wird, kann man "kostenlos" was in die oberen 0.5 GB auslagern. Und hat dann hoffentlich genug Zeit bis zum wieder einlesen, dass irgendwann auch mal in die ersten 3.5 GB geschrieben wird. (wobei ich keine Ahnung habe, in wie fern OS / API / Treiber / Engine solche feinen Optimierungen überhaupt zulassen würden)

MrS
Eine Grafikkarte oder der Treiber kann nicht wichtige Daten und unwichtige unterscheiden er weiß nicht welcher Speicher wann abgerufen werden muss Es wird wonach speicherbelegt. Das mit dem 512 MB kann man nicht Treiber seitig lösen

[Freed]

Wenn man eine Quelle angibt sollte man diese allerdings auch vollständig lesen.



Die volle Bandbreite kann also durchaus erreicht werden, allerdings nur wenn man in einem Segment liest und im anderen schreibt.

Danke Gast!

Was ist denn das für eine Aussage? Muss ich dann jetzt immer das Kleingedruckte lesen, ob die Speicherbandbreite jetzt lesen oder schreiben oder Mischbetrieb ist? Die Aussage ist vom gleiche Kaliber wie "sind doch 4 GB, nur halt 3,5 + 0,5" - kommst Du von nvidia und versuchst die Wogen zu glätten?

Und die Tatsache, dass sich 2 Segmente einen L2-Cache teilen, dürfte wohl auch dazu führen, dass es zu Latenzen kommt und Deine Behauptung, dass trotzdem die Bandbreite der Spezifikationen erreicht werden kann ist zweifelhaft.

[Gast]

Hui Achtung! Wenn diese Sicht der Dinge von nVidia wirklich als Argument für ein "GTX970 hat 256bit Memory Interface" gebracht wird, dann mache ich mir Sorgen, welche Quirks uns die VGA-Chip Hersteller in Zukunft als technische Merkmale verkaufen wollen.

Die Karte hat 4GiB an Speicher und ein volles 256bit Interface daran gibt es nicht das geringste zu rütteln.

Der Chip wurde erst weiter "drinnen", beim Crossbar zwischen den GPCs und dem Speichercontroller.

Die Aussage, dass die 970GTX kein 256bit Interface hat wäre in etwa das selbe, zu behaupten dass die Karte keine 56 ROPs hat, schließlich können auch nur 52 Pixel pro Takt erzeugt werden und die restlichen 4 sind in den meisten Fällen auch arbeitslos.

In weiterer Folge müsste man jeder im Kern beschnittenen Karte mit vollem Speicherinterface dieses absprechen, schließlich wird auch dort die theoretische Speicherbandbreite kaum erreicht, da einfach ein teil der Consumer welche diese verwerten könnten fehlt.

[MrSpadge]

Solche Angaben sind ohne echte Details sogut wie wertlos. Aus einem bidirektionalem Bus ohne nähere Angaben folgt nicht, dass der L2-Cacheblock gleichzeitig Lese- und Schreib-Transaktionen mit jeweils voller Bandbreite vornehmen kann.
Aber deinem Argument "da ist kein passender Datenpfad" ist damit erstmal der Wind aus den Segeln genommen. Allerdings stimmt es, dass daraus nicht folgt, dass die gleichzeitige Nutzung von Lese- und Schreiboperationen möglich sein muss. Und, dass wir da ohne Details nicht weiterkommen - möglich ist beides. Zumal ein Cache nicht für jeden Zugriff nötig ist, je nach Architektur kann er auch übergangen werden, wenn das gerade schneller & effizienter ist.

Anbieten kann ich dazu noch die Aussage (http://www.anandtech.com/comments/8935/geforce-gtx-970-correcting-the-specs-exploring-memory-allocation/437798) von Ryan Smith von Anandtech, der zumindest direkt mit nvidia gesprochen hat und explizit bestätigt, dass die volle Bandreite im Mischbetrieb erreicht werden kann. Einen Beweis tritt er dafür natürlich nicht an - aber auch nichts Gegenteiliges.

Vielleicht könnte jemand mal ein kleines OpenCL oder CUDA Testprogramm schreiben? Etwas über 3.5 GB RAM reservieren, im unteren Teil lesen (weit genug weg von der 3.5 GB Grenze) und zusätzlich in den restlichen Speicher schreiben. Dabei die effektive Bandbreite messen.

Eine Grafikkarte oder der Treiber kann nicht wichtige Daten und unwichtige unterscheiden er weiß nicht welcher Speicher wann abgerufen werden muss Es wird wonach speicherbelegt. Das mit dem 512 MB kann man nicht Treiber seitig lösen
Vorstellen kann ich mir das z.B. bei irgendwelchen Ausgabepuffern, in die man ab und an schreibt, und die irgendwann mal transferiert werden sollen. Oder wenn Daten schon mal vorbereitend über den PCIe geladen werden - dann könnte man die erstmal in den für's normale rendering nutzlosen 512 MB ablegen. Oder wenn Ressourcen evtl. nicht mehr gebraucht werden, aber noch Platz im Speicher ist - dann kann man die erstmal in die 512 MB verschieben und schneller zugreifen, falls sie doch noch gebraucht werden. Insgesamt wäre das also mehr wie ein Cache zwischen RAM&PCIe und dem VRAM. Die Karte selbst kann sowas nicht entscheiden, dem Treiber würde ich da aber mehr zutrauen.

Optimierungen könnten auch mit "DX12’s explicit memory management (http://www.anandtech.com/show/8962/the-directx-12-performance-preview-amd-nvidia-star-swarm/2)" möglich werden. Wobei ich eher hoffe, dass solche "krummen" Konfigurationen in Zukunft die Ausnahme bleiben. ROPs und L2$ können sie von mir aus bei Bedarf ruhig teilweise deaktivieren, solange die Speichercontroller weiterhin ihren Dienst tun können.

MrS

[aths]

Die Karte hat 4GiB an Speicher und ein volles 256bit Interface daran gibt es nicht das geringste zu rütteln.

Der Chip wurde erst weiter "drinnen", beim Crossbar zwischen den GPCs und dem Speichercontroller.

Die Aussage, dass die 970GTX kein 256bit Interface hat wäre in etwa das selbe, zu behaupten dass die Karte keine 56 ROPs hat, schließlich können auch nur 52 Pixel pro Takt erzeugt werden und die restlichen 4 sind in den meisten Fällen auch arbeitslos.Mit dem gleichen Argument könnte man 3,5 GB anschließen aber 4 GB verbauen und behaupten, es handele sich um eine 4-GB-Karte.

Ein Speicherinterface mit 256 physikalischen Datenpfaden, von denen sich aber nur bis zu 224 Bit nutzen lassen, ist mit "256 Bit" nicht hinreichend beschrieben.



Aber deinem Argument "da ist kein passender Datenpfad" ist damit erstmal der Wind aus den Segeln genommen. Allerdings stimmt es, dass daraus nicht folgt, dass die gleichzeitige Nutzung von Lese- und Schreiboperationen möglich sein muss. Und, dass wir da ohne Details nicht weiterkommen - möglich ist beides. Zumal ein Cache nicht für jeden Zugriff nötig ist, je nach Architektur kann er auch übergangen werden, wenn das gerade schneller & effizienter ist.Dass Caches übergangen werden können, ist angesichts der hohen Latenzen beim Speicherzugriff unüblich und im Schaubild auch nicht eingezeichnet. Man liest oder schreibt in Bursts. Die müssen gepuffert werden.

Du zitierst jemand der mit Nvidia gesprochen hat und seine Ausführungen nicht näher erläutert. Da ist die Aussagekraft nicht hoch.

Das eigentliche Argument bleibt bestehen: Die Daten werden im 3,5-GB-Bereich interleaved über sieben Chips verteilt abgelegt. Zugriff darauf muss immer komplett erfolgen. Es ist völlig unklar, inwiefern man gleichzeitig auf die letzten 0,5 GB eine Transaktion vornehmen können soll und warum nicht gleichzeitiges Lesen gehen soll, aber Lesen auf der einen und Schreiben auf der anderen Partition.

Selbst wenn es möglich sein sollte – ich gehe davon aus, dass es nicht möglich ist – bringt es nichts. Daten speichert man, um sie später zu lesen. Wenn man beim Lesen den 3,5-GB-Bereich blockiert, ist das der Hemmschuh.

[MrSpadge]

Dass Caches übergangen werden können, ist angesichts der hohen Latenzen beim Speicherzugriff unüblich und im Schaubild auch nicht eingezeichnet. Man liest oder schreibt in Bursts. Die müssen gepuffert werden.
Beim Schreiben mit Sicherheit - bis da mal die richtigen Zellen adressiert sind und der Burst anfangen kann, dauert's aus Sicht des Chips ewig. Aber beim Lesen? Wenn der Chip weiß, wo die Daten hinsollen, wozu sie dann erst noch im L2 ablegen und warten?

Du zitierst jemand der mit Nvidia gesprochen hat und seine Ausführungen nicht näher erläutert. Da ist die Aussagekraft nicht hoch.
Das stimmt schon - nur haben wir was besseres, außer "ich und mein Bauch glauben das nicht"?
Das eigentliche Argument bleibt bestehen: Die Daten werden im 3,5-GB-Bereich interleaved über sieben Chips verteilt abgelegt. Zugriff darauf muss immer komplett erfolgen. Es ist völlig unklar, inwiefern man gleichzeitig auf die letzten 0,5 GB eine Transaktion vornehmen können soll und warum nicht gleichzeitiges Lesen gehen soll, aber Lesen auf der einen und Schreiben auf der anderen Partition.
Sätze 1 und 2: Zustimmung. Dann: dass Lesen nicht gleichzeig geht, ist doch seit dem ersten Artikel von Anandtech klar. Der Bus zwischen crossbar, L2 und Speichercontroller ist immer 32 Bit breit. In eine Richtung passen da pro Takt halt nur 32 Bit durch. Es gbit zwar die Querverbindung zum "handicap-Speichercontroller" mit ebenfalls 32 Bit, aber nicht vom crossbar aus, sondern zu spät. Das einzige, was diese Datenleitungen im gleichen Takt ermöglichen könnten, wären Transfers in verschiedene Richtungen unter Ausnutzung der Bidirektionalität.

Einen harten Beweis, dass das geht, haben wir nicht. Aber eben auch keinen Beweis, dass es nicht ginge.

Selbst wenn es möglich sein sollte – ich gehe davon aus, dass es nicht möglich ist – bringt es nichts. Daten speichert man, um sie später zu lesen. Wenn man beim Lesen den 3,5-GB-Bereich blockiert, ist das der Hemmschuh.
Ich wage auch nicht, zu behaupten, dass diese 0.5 GB jemals effizient eingesetzt werden können. Wenn ich (und Ryan) jedoch Recht habe(n), ist die Hauptaussage des Artikels, um den es hier geht ("die 256 Bit Bandbreite können nie genutzt werden"), aber falsch. Das ganze Theater kann und muss man nVidia dann moralisch vorwerfen, es sind (so wie ich das sehe) aber keine technischen und rechtlichen Falschaussagen, sondern "nur" irreführende unvollständige Angaben.

MrS

[aths]

Dein Erklärungsversuch mit Bidirektionalität erklärt aus meiner Sicht nichts. Die Daten müssen irgendwoher kommen und irgendwohin geschrieben werden. Es ergibt keinen Sinn, anzunehmen, dass Nvidia den L2-Cache so designt hat dass er pro Takt 32 Bit aus dem RAM lesen und gleichzeitig 32 Bit in den RAM schreiben kann.

Die Frage ist doch, wofür das Speicherinterface konstruiert wurde. Es ging Nvidia darum, die Bandbreite zu senken. Hätten sie den verfügbaren RAM senken wollen, hätten sie die Karte gleich als Version mit nur sieben RAM-Bausteinen gebracht.

Warum sollte Nvidia erst das Interface bewusst auf 224 Bit senken, es dann aber so bauen, doch 256 Bit nutzen zu können? Dass es je nach genauem Aufbau und dem möglichen Vorhandensein von Extra-Puffern ganz kurzzeitig nicht auszuschließen ist, dass in einem Takt alle 256 Leitungen Daten transportieren, ist irrelevant für das, was hinten rauskommt. Dass es überhaupt möglich ist, lässt sich anhand der bekannten Daten und Nvidias Schaubild ausschließen. Ein vollständiger Beweis ist es nicht, aber wenn Nvidia in den offiziellen Specs nicht mal die 4 GB mit einer näheren Erläuterung versieht, warum sollte man beim Interface von angeblich 256 Bit der offiziellen Angabe glauben?

Wenn es möglich wäre, warum hat Nvidia nicht von sich aus beschrieben, wie es funktionieren soll? Die Jungs lassen ja sonst keine Gelegenheit aus, zu jubeln, wie toll ihr Produkt ist.

[Gast]

Warum sollte Nvidia erst das Interface bewusst auf 224 Bit senken, es dann aber so bauen, doch 256 Bit nutzen zu können?


Nvidia hat nicht das Interface verringert, sondern den ROP/L2-Block reduziert, vermutlich um mehr verkaufbare GM204 Chips zu bekommen.

Hätte Nvidia ein 224bit Interface gewollt, hätte man gleich auch den weiteren Speichercontroller deaktivieren können, und damit den Yield sogar noch weiter erhöht. Man hätte genauso 2 Speicherchips am verbleibenden Controller anschließen können um auf die 4GiB zu kommen.

Im Gegenteil, Nvidia hat Maxwell absichtlich so gebaut, dass es möglich ist ROPs/L2-Cache zu deaktivieren, ohne dass man den Speichercontroller ebenfalls deaktivieren muss, mit den älteren GPUs wäre das gar nicht möglich.

[Gast]

Dein Erklärungsversuch mit Bidirektionalität erklärt aus meiner Sicht nichts. Die Daten müssen irgendwoher kommen und irgendwohin geschrieben werden. Es ergibt keinen Sinn, anzunehmen, dass Nvidia den L2-Cache so designt hat dass er pro Takt 32 Bit aus dem RAM lesen und gleichzeitig 32 Bit in den RAM schreiben kann.


Es geht nicht um den L2 Cache, der Pfad zwischen L2 und Speicher (mit dem "buddy interface" ist breit genug um beide Speicherchips gleichzeitig anzusprechen.
Was nicht breit genug ist, ist allerdings der weitere Pfad von L2 zum Crossbar, auf dieser Seite gibt es nämlich kein "buddy interface".

Da dieser Pfad aber bidirektional ist, kann die volle Datenrate zwischen GPU und Speicher (welche immer möglich ist) nur dann durchgehend ausgenutzt werden wenn zwischen Crossbar und L2 ständig in beide Richtung Daten fließen.

Dauerhaft wird das natürlich niemals der Fall sein, kurzfristig aber immer wieder möglich, auch durch den L2 Cache, dieser fungiert ja als Puffer, weshalb die Daten ja nicht unbedingt immer sofort gelesen/geschrieben werden müssen, sonder gepuffert werden können um sie dann in einem Burst rauszuschreiben bzw. zu lesen.

[MrSpadge]

@Gast2: ja, genau so klingt es meiner Meinung nach richtig.

Was mir noch zu Aths Argument eingefallen ist, dass der L2 evtl. gar nicht 2 x 32 bidirektionale Bits pro Takt aufnehmen/rausgeben kann: in jedem Fall muss er mindestens einen Lese- und einen Schreib-Port gleichzeitig nutzt können. Sonst könnte ein normaler Stream aus cross bar -> L2 -> RAM nicht aufrecht erhalten werden. Ob er noch mehr Ports hat (sicher nicht mehr als im Normalfall nötig) und ob diese mindestens zwei gleichzeitig nutzbaren Ports auch von "der gleichen Seite" her ansprechbar sind - wer weiß, ausgeschlossen ist's aber sicher nicht. Es könnte z.B. so gebaut sein wie in Intels CPUs, wo die L3$ Segmente Stationen am Ringbus sind. hier ist es dann egal, aus welcher Richtung die Daten kamen. Sowas ist zwar auch nicht in nvidias Skizze eingezeichnet.. allerdings sind dort eh keine Details eingezeichnet. Nebenbei: diese Auslegung wäre auch praktisch, wenn man vom RAM gelesene Daten am L2 vorbeischleusen will.

MrS

[Gast]

Im Gegenteil, Nvidia hat Maxwell absichtlich so gebaut, dass es möglich ist ROPs/L2-Cache zu deaktivieren, ohne dass man den Speichercontroller ebenfalls deaktivieren muss, mit den älteren GPUs wäre das gar nicht möglich.

Was mir noch zu Aths Argument eingefallen ist, dass der L2 evtl. gar nicht 2 x 32 bidirektionale Bits pro Takt aufnehmen/rausgeben kann: in jedem Fall muss er mindestens einen Lese- und einen Schreib-Port gleichzeitig nutzt können. Sonst könnte ein normaler Stream aus cross bar -> L2 -> RAM nicht aufrecht erhalten werden. Ob er noch mehr Ports hat (sicher nicht mehr als im Normalfall nötig) und ob diese mindestens zwei gleichzeitig nutzbaren Ports auch von "der gleichen Seite" her ansprechbar sind - wer weiß, ausgeschlossen ist's aber sicher nicht. Es könnte z.B. so gebaut sein wie in Intels CPUs, wo die L3$ Segmente Stationen am Ringbus sind. hier ist es dann egal, aus welcher Richtung die Daten kamen. Sowas ist zwar auch nicht in nvidias Skizze eingezeichnet.. allerdings sind dort eh keine Details eingezeichnet. Nebenbei: diese Auslegung wäre auch praktisch, wenn man vom RAM gelesene Daten am L2 vorbeischleusen will.

Yeaah Right
Its not a Bug - Its a Feature

Sowas nenn ich Leugnen auf hohem Niveau, Bis zuletzt wird mit Händen und Füseen und "abstrussen" Theorien abgelehnt was passiert ist.
Nvidia hat einfach nur seinen "Gewinn" maximiert und euch das Geld aus der Tasche gezogen.


BTW - Selbst wenn diese "ungewöhnliche" Anbindung stimmt
Ist es UNMÖGLICH mit ihr 256bit lesend FULLSPEED zu erreichen.

[Gast]

BTW - Selbst wenn diese "ungewöhnliche" Anbindung stimmt
Ist es UNMÖGLICH mit ihr 256bit lesend FULLSPEED zu erreichen.


Das ist schon möglich, es kann so lange Fullspeed gelesen werden bis der L2-Block im letzen Speichercontroller voll ist.

Die Daten können "nur" nicht schnell genug weitergegeben werden um die volle Datenrate dauerhaft aufrecht zu erhalten (außer man hat genau das richtige Verhältnis an Lese- und Schreibzugriffen). Kurzfristig kann aber immer wieder die volle Datenrate erreicht werden.

[Gast]

Das ist schon möglich, es kann so lange Fullspeed gelesen werden bis der L2-Block im letzen Speichercontroller voll ist.

Die Daten können "nur" nicht schnell genug weitergegeben werden um die volle Datenrate dauerhaft aufrecht zu erhalten (außer man hat genau das richtige Verhältnis an Lese- und Schreibzugriffen). Kurzfristig kann aber immer wieder die volle Datenrate erreicht werden.


"LESEND"
und wenn du dir das Schaubild anschaust , auf welcher Leitung überträgt du die "letzten" 32bit GLEICHZEITIG ?

[Gast]

"LESEND"
und wenn du dir das Schaubild anschaust , auf welcher Leitung überträgt du die "letzten" 32bit GLEICHZEITIG ?

32bit gehen vom L2 auf dem herkömmlichen Weg, 32bit vom L2 über das "buddy interface" zum Speicher. Das sollte laut dem Artikel von anandtech möglich sein.

Was natürlich nicht möglich ist, sind in einem Takt 64bit aus dem Speichercontrollerblock in den Crossbar zu leiten, außer es sind 32bit lesend und 32bit schreibend (da Duplexfähig).

Nvidia hätte wohl ein derartiges "buddy interface" auf beiden Seiten des L2 einbauen sollen, dann hätte man diese Probleme nicht und es könnten in jedem Takt 64bit zwischen Speichercontroller und Crossbar sowie 64bit zwischen Speichercontroller und RAM laufen.
So sind die 64bit nur zwischen Speichercontroller und RAM möglich, zwischen Speichercontroller und Crossbar nur eingeschränkt.

[Gast]

32bit gehen vom L2 auf dem herkömmlichen Weg, 32bit vom L2 über das "buddy interface" zum Speicher. Das sollte laut dem Artikel von anandtech möglich sein.

Was natürlich nicht möglich ist, sind in einem Takt 64bit aus dem Speichercontrollerblock in den Crossbar zu leiten, außer es sind 32bit lesend und 32bit schreibend (da Duplexfähig).

Nvidia hätte wohl ein derartiges "buddy interface" auf beiden Seiten des L2 einbauen sollen, dann hätte man diese Probleme nicht und es könnten in jedem Takt 64bit zwischen Speichercontroller und Crossbar sowie 64bit zwischen Speichercontroller und RAM laufen.
So sind die 64bit nur zwischen Speichercontroller und RAM möglich, zwischen Speichercontroller und Crossbar nur eingeschränkt.


Und wenn du dich noch so drehst und windest !

Bei 7 Leitungen kommen durch die Crossbar NIE 256bit.
Aus Amen babella

Ende der Diskussion - Hier werden ja schon technische FAKTEN verleugnet

[Gast]

Bei 7 Leitungen kommen durch die Crossbar NIE 256bit.
Aus Amen babella


Habe ich auch nicht behauptet. Das heißt aber nicht dass nicht 256bit nach dem Crossbar in den Speicher wandern können bzw. umgekehrt.
Die Daten müssen ja nicht zwangsläufig immer sofort durch den Crossbar, da ist ja noch ein Cache drinnen der diese puffern kann.

[aths]

Nvidia hat nicht das Interface verringert, sondern den ROP/L2-Block reduziert, vermutlich um mehr verkaufbare GM204 Chips zu bekommen.

Hätte Nvidia ein 224bit Interface gewollt, hätte man gleich auch den weiteren Speichercontroller deaktivieren können, und damit den Yield sogar noch weiter erhöht. Man hätte genauso 2 Speicherchips am verbleibenden Controller anschließen können um auf die 4GiB zu kommen.

Im Gegenteil, Nvidia hat Maxwell absichtlich so gebaut, dass es möglich ist ROPs/L2-Cache zu deaktivieren, ohne dass man den Speichercontroller ebenfalls deaktivieren muss, mit den älteren GPUs wäre das gar nicht möglich.
L2-Cache nimmt vermutliich nicht so viel Platz weg, als dass man hier dringend einen Salvage-Part bräuchte. Selbst wenn es so wäre, ändert es nichts daran, dass die 970 effektiv ein 224-Bit-Interface für 3,5 GB RAM hat.


Es geht nicht um den L2 Cache, der Pfad zwischen L2 und Speicher (mit dem "buddy interface" ist breit genug um beide Speicherchips gleichzeitig anzusprechen.
Was nicht breit genug ist, ist allerdings der weitere Pfad von L2 zum Crossbar, auf dieser Seite gibt es nämlich kein "buddy interface".

Da dieser Pfad aber bidirektional ist, kann die volle Datenrate zwischen GPU und Speicher (welche immer möglich ist) nur dann durchgehend ausgenutzt werden wenn zwischen Crossbar und L2 ständig in beide Richtung Daten fließen.

Dauerhaft wird das natürlich niemals der Fall sein, kurzfristig aber immer wieder möglich, auch durch den L2 Cache, dieser fungiert ja als Puffer, weshalb die Daten ja nicht unbedingt immer sofort gelesen/geschrieben werden müssen, sonder gepuffert werden können um sie dann in einem Burst rauszuschreiben bzw. zu lesen.
Ob es ganz kurzzeitig möglich ist, eine Cacheline über alle 8 RAMs zu bursten, ist in der Praxis belanglos da zuerst die 3,5 GB genutzt werden. Mit einer Bandbreite von 224 Bit.

Wäre es möglich, die letzten 0,5 GB ohne echten Verlust mitzunutzen, wäre die Partitionierung in 3,5+0,5 nicht erforderlich. Man könnte dann gleich über alle 8 RAMs die Daten interleaved ablegen. Kann man aber nicht. Weil das Interface für gleichzeitigen Zugriff nicht breit genug ist.

[aths]

@Gast2: ja, genau so klingt es meiner Meinung nach richtig.

Was mir noch zu Aths Argument eingefallen ist, dass der L2 evtl. gar nicht 2 x 32 bidirektionale Bits pro Takt aufnehmen/rausgeben kann: in jedem Fall muss er mindestens einen Lese- und einen Schreib-Port gleichzeitig nutzt können. Sonst könnte ein normaler Stream aus cross bar -> L2 -> RAM nicht aufrecht erhalten werden. Ob er noch mehr Ports hat (sicher nicht mehr als im Normalfall nötig) und ob diese mindestens zwei gleichzeitig nutzbaren Ports auch von "der gleichen Seite" her ansprechbar sind - wer weiß, ausgeschlossen ist's aber sicher nicht. Es könnte z.B. so gebaut sein wie in Intels CPUs, wo die L3$ Segmente Stationen am Ringbus sind. hier ist es dann egal, aus welcher Richtung die Daten kamen. Sowas ist zwar auch nicht in nvidias Skizze eingezeichnet.. allerdings sind dort eh keine Details eingezeichnet. Nebenbei: diese Auslegung wäre auch praktisch, wenn man vom RAM gelesene Daten am L2 vorbeischleusen will.

MrS
Ich verstehe noch immer nicht, warum du auf bidirektionalen Leitungen herumreitest oder einen Datenpfad um den L2-Cache herum suchst. Letzteres ergibt keinen Sinn und ersteres ist für das Argument belanglos:

Die 970 nutzt zunächst bis zu 3,5 GB RAM in einer 7x32-Bit-Konfiguration. Macht 224 Bit. Die letzten 0,5 GB werden so gut es geht nicht genutzt. Das ergäbe keinen Grund, wenn dieser Speicher leicht zugänglich wäre.

[aths]

Habe ich auch nicht behauptet. Das heißt aber nicht dass nicht 256bit nach dem Crossbar in den Speicher wandern können bzw. umgekehrt.
Die Daten müssen ja nicht zwangsläufig immer sofort durch den Crossbar, da ist ja noch ein Cache drinnen der diese puffern kann.Selbst wenn möglich wäre, irgendwie, obwohl es das Schaubild nicht hergibt: Ganz überwiegend läuft die 970 im exklusiven 3,5-GB-Modus. Mit 224 Bit.

Doch es gibt laut Nvidia-Schaubild einen Flaschenhals von L2-Cache zum Memorycontroller. Der ist offenkundig nur 32 Bit breit, also so viel wie der Speicher pro Takt liefert. Alles andere ergäbe auch keinen Sinn. Schon alleine durch den Interleaved-Modus der ersten sieben RAMs ist der Zugriff aus rein logischen Gründen auf den externen Speicher exklusiv. Wir reden von GPU-zu-RAM-Bandbereite, nicht GPU-zu-Cache-Bandbreite.

Wobei letztere logischerweise ebenfalls um 1/8 geringer ist als bei der 980.

[Malabolge]

Habe ich auch nicht behauptet. Das heißt aber nicht dass nicht 256bit nach dem Crossbar in den Speicher wandern können bzw. umgekehrt.
Die Daten müssen ja nicht zwangsläufig immer sofort durch den Crossbar, da ist ja noch ein Cache drinnen der diese puffern kann.

Und dann kam Mose und teilte das Rote Meer ....

Upps - Tschuldigung , Natürlich war es Nvidia und teilte die Leitungen
Und plötzlich konnten mehr Bit "fliesen"


Wie schrieb ein Gast so nett : "Fifty Shades of Green"



Ps: "nicht 256bit nach dem Crossbar "aus 224bit vor der "Engstelle" können nicht 256bit nach der engstelle werden.
(empfehle Texas Lightning : "No No Never")

[Gast]

Ps: aus 224bit vor der "Engstelle" können nicht 256bit nach der engstelle werden.
(empfehle Texas Lightning : "No No Never")

Aber es können jeden Takt 256bit aus dem L2 in den RAM bzw. umgekehrt wandern.

Dass das auf Dauer nicht sinnvoll ist weil die Daten so schnell nicht weiter können steht auf einem anderen Blatt, das Interface bleibt technisch trotzdem bei 256bit.

[aths]

Aber es können jeden Takt 256bit aus dem L2 in den RAM bzw. umgekehrt wandern.

Dass das auf Dauer nicht sinnvoll ist weil die Daten so schnell nicht weiter können steht auf einem anderen Blatt, das Interface bleibt technisch trotzdem bei 256bit.
Die sieben Caches können nicht gleichzeitig acht Speichercontroller bedienen, so dass die Cache-zur-Speicher-Bandbreite keine 256 Bit pro Takt beträgt.

[Spasstiger]

Die Speicherbandbreite der GTX 970 ist ja den bisherigen Messungen nach definitiv geringer als die der GTX 980 trotz identischer Spezifikationen. Es ist noch kein Beweis erbracht worden, dass die GTX 970 in irgendeinem Szenario die Speicherbandbreite der GTX 980 erreicht.
NV wird sich zu diesem Punkt sicherlich nicht mehr äußern.

[Gast]

Die sieben Caches können nicht gleichzeitig acht Speichercontroller bedienen, so dass die Cache-zur-Speicher-Bandbreite keine 256 Bit pro Takt beträgt.

Doch, hat eigentlich irgendwer die Artikel von Anandtech bzw. pcper auch gelesen?

Die 7 Cache Blöcke können 8 Speicherchips bedienen, genau dafür wurde ja die zusätzliche Verbindung in Maxwell (zumindest in GM204) eingebaut, die es ja bei Kepler noch gar nicht gab, eingebaut.

Die 7 Cache-Blöcke können allerdings nicht die Datenrate, welche von 8 Speicherblöcken ankommen in einem Takt auch weiter in den Kern leiten.

Deshalb können die 256bit in der Realität niemals dauerhaft erreicht werden (könnten natürlich schon aber nur wenn die Daten lediglich zwischen L2 und RAM wandern, was natürlich sinnlos ist), und deshalb wird auch niemals ein Benchmark die volle Bandbreite zeigen können da diese natürlich deutlich länger laufen, als der 256bit Burst erreichbar ist.

[Malabolge]

Doch, hat eigentlich irgendwer die Artikel von Anandtech bzw. pcper auch gelesen?

Die 7 Cache Blöcke können 8 Speicherchips bedienen, genau dafür wurde ja die zusätzliche Verbindung in Maxwell (zumindest in GM204) eingebaut, die es ja bei Kepler noch gar nicht gab, eingebaut.

Die 7 Cache-Blöcke können allerdings nicht die Datenrate, welche von 8 Speicherblöcken ankommen in einem Takt auch weiter in den Kern leiten.

Deshalb können die 256bit in der Realität niemals dauerhaft erreicht werden (könnten natürlich schon aber nur wenn die Daten lediglich zwischen L2 und RAM wandern, was natürlich sinnlos ist), und deshalb wird auch niemals ein Benchmark die volle Bandbreite zeigen können da diese natürlich deutlich länger laufen, als der 256bit Burst erreichbar ist.


Und sie leugnen immer noch !!!

Nochmal wenn wenn leitung 8 die "Letzten" 32bit gelesen werden, Dann haben die Leitungen 1-7 SENDEPAUSE , BLOCKADE , RUHEZEIT
Also 224 bit Max ODER 32 bit "Neben" nicht PLUS. 256bit werden NIE erreicht

Es ist zum Kotzen , man kann einfach nicht der Wahrheit ins Auge sehen:
NVIDIA hat die Käufer der 970 wissentlich,willentlich und ordentlich über den Löffel balbiert.
Das sie dabei auch AMD um Verkaufszahlen gebracht haben, gibt dem ganzen schon mafiöse Züge.


Aber der eine oder andere SPAM und Werbeaccount hier muss ja das letzte Wort haben und das ganze relativieren

[Gast]

Es ist zum Kotzen , man kann einfach nicht der Wahrheit ins Auge sehen:

Es ist zum Kotzen wenn man Dinge schlechter reden will, als sie wirklich sind, und es ist noch mehr zum Kotzen wenn leute nicht lesen können.

Nochmal zum mitschreiben:
Meanwhile there’s one other new feature here that’s activated only on the partially disabled partition, and that’s the link between the first and second units of the ROP partition. Typically each ROP/L2 unit would have a link to a port on the crossbar and a link to its own dedicated 32-bit memory controller channel; however because GTX 970 disabled a ROP/L2 unit, the “buddy” link comes in to play. This link is essentially the lynchpin of Maxwell’s new partial disable functionality, and allows the second half of the memory controller to stay active. This link only needs to be active when a ROP/L2 unit is disabled, and NVIDIA has confirmed that it is a full bandwidth link identical to the normal ROP/L2 to MC link, meaning it’s capable of 4 32 byte requests per clock (2 reads and 2 writes). Ultimately this link is what makes a partially disabled partition possible, and is also what makes it possible to have the full 256-bit memory bus present and active in spite of the lack of a ROP/L2 unit and its associated crossbar port.


The crossbar port and its attached ROP/L2 unit can access both memory channels at once, splitting up the 4 operations among them, but there is only 1 read return bus and 1 write data bas, and hence in practice it cannot issue identical operations to both memory channels at once .

Despite all of this, achieving peak memory bandwidth performance on the GTX 970 is still possible, but it requires much more effort since simple striping will not do the trick. The easiest and most effective solution in this regard is to interleave reads and writes over the segments, such that one segment is writing while another segment is reading. Interleaving in this fashion allows both segments to work at once – avoiding the blocking effect of the shared read and write buses – and makes it more likely that both segments are doing useful work rather than waiting for their turn on an operation.

Falls sich doch jemand dafür entscheidet sich näher über die technischen Hintergründe der 970GTX zu informieren, anstatt irgendwelche emotionale Hasspostings loszuwerden, hier nochmal der Link zum kompletten Artikel:
http://www.anandtech.com/show/8935/geforce-gtx-970-correcting-the-specs-exploring-memory-allocation

[MrSpadge]

Malabolge, komm mal wieder runter!

Wenn Leitungen 1 bis 7 lesen, kann Leitung 8 nicht lesen (und umgekehrt). Wenn Leitungen 1 bis 7 schreiben, kann Leitung 8 nicht schreiben (und umgekehrt). Deshalb kann kein Tool einen 256 Bit Zugriff messen - weil die immer nur lesen oder schreiben. So weit waren wir doch schon mal.

Wenn aber Leitungen 1 bis 7 lesen, kann nach Ryans Aussage Leitung 8 durchaus schreiben (und umgekehrt). Das beißt sich weder mit dem parallelen "stride"-Zugriff auf Leitungen 1-7 noch mit den Datenleitungen zwischen Speichercontrollern und L2, noch mit den Datenleitungen zwischen L2 und Crossbar. So viel ist klar, wenn man weiß, dass die Leitungen in nVidias Schaubild bidirektional sind (deshalb bringe ich diesen Punkt immer wieder zur Sprache, Aths).

Danach gibt es aus meiner Sicht nur noch 2 Punkte, die einen 256 Bit Zugriff im gemischten Lese-/Schreibbetrieb verhindern könnten:

1. Wenn der L2 zum Speichercontroller nur einen kombinierten Lese-/Schreibport hat, kann er nicht beides gleichzeitig leisten. Hat er aber 2 dedizierte Ports, ist's kein Problem. Wie es wirklich ist, wissen wir nicht. Möglich wäre auch, den L2 in bestimmten Fällen zu umgehen (wenn er nicht gebraucht wird). Oder, die Eingangs- und Ausgangsports zu kombinieren (wie in Intels Ringbus). Ob etwas davon nötig ist und benutzt wird, wissen wir auch nicht. Was wir jedoch wissen ist, dass nVidia diese Möglichkeit explizit im Design vorgesehen hat - sonst hätten sie das "buddy interface" nicht eingebaut. Da ist es auch denkbar, dass sie den Rest auch angepasst haben, insofern der Aufwand dafür nicht zu hoch war.

2. Software: wie Aths richtig bemerkt, versucht der Treiber momentan einfach nur, die ersten 3.5 GB zu nutzen und den restlichen Bereich zu vermeiden. Das ist sicher besser als ein "blinder Mischbetrieb" beider Bereiche, limitiert die praktisch nutzbare Bandbreite aber auch streng auf 224 Bit.

Bedeutet das nun, dass 256 Bit technisch wirklich nicht möglich sind und auch software-seitig nie nutzbar sein werden? Der Artikel von Leo, um den es hier in dieser Diskussion geht (oder gehen sollte?) stellt es auch genau so dar - aus meiner Sicht ist das jedoch falsch. Aths würde dem vielleicht mit Mühe und Not zustimmen. Aber berechtigterweise anmerken, dass hier aus seiner Sicht die falsche Frage gestellt wird. Denn praktisch läuft die Karte ja momentan klar mit 224 oder 32 Bit. Weiter werdenwir uns hier wohl kaum einigen können, solange wir neuen detaillierteren technischen Informationen bekommen. Oder jemand die Sache mit dem kombinierten Lese-/Schreibmodus testet.

MrS

[Malabolge]

"LESEND"
und wenn du dir das Schaubild anschaust , auf welcher Leitung überträgt du die "letzten" 32bit GLEICHZEITIG ?

Touche ! Besser kann es nicht ausdrücken.

Sicherlich kan das "Interface" 256bit im irgendeiner seltsamen "Mischart" aus Lesen (224) und Schreiben (32) erreichen
Aber niemals Lesend 256 oder Schreibend 256 "am Stück" !

Obwohl , am 29. Februar dieses Jahres sicher möglich

[aths]

Doch, hat eigentlich irgendwer die Artikel von Anandtech bzw. pcper auch gelesen?

Die 7 Cache Blöcke können 8 Speicherchips bedienen, genau dafür wurde ja die zusätzliche Verbindung in Maxwell (zumindest in GM204) eingebaut, die es ja bei Kepler noch gar nicht gab, eingebaut.

Die 7 Cache-Blöcke können allerdings nicht die Datenrate, welche von 8 Speicherblöcken ankommen in einem Takt auch weiter in den Kern leiten.

Deshalb können die 256bit in der Realität niemals dauerhaft erreicht werden (könnten natürlich schon aber nur wenn die Daten lediglich zwischen L2 und RAM wandern, was natürlich sinnlos ist), und deshalb wird auch niemals ein Benchmark die volle Bandbreite zeigen können da diese natürlich deutlich länger laufen, als der 256bit Burst erreichbar ist.
Mir nur sieben statt acht Chips ist auch die Bandbreite von Cache zu RAM um 1/8 geringer. Ein Cache-Baustein kann nicht gleichzeitig zwei Memorycontroller bedienen. Das ist im Schaubild auf PCPer auch so eingezeichnet: Die beiden Memorycontroller kommunizieren untereinander. Der L2-Block selbst bedient nur einen Memorycontroller.


nach Ryans Aussage
Ryans Aussage ist keine Primärquelle. Sie widerspricht einer Primärquelle, dem Schema von Nvidia. Man fragt sich auch, warum Nvidia erst das Interface kürzt, dann aber eine umständliche Methode einbauen sollte, doch irgendwie 256-Bit-Zugriff zu erlauben.

Mit nur sieben L2-Blöcken ist die Bandbreite geringer. Es betrifft die Bandbreite von Crossbar zum L2, und die vom L2 zum Speicher.

Die Speicher-Organisation spricht ebenfalls dagegen. Wenn man den achten RAM benutzt, ist der siebte RAM nicht benutzbar. Ob lesend oder schreibend.

[Gast]

Das ist im Schaubild auf PCPer auch so eingezeichnet: Die beiden Memorycontroller kommunizieren untereinander. Der L2-Block selbst bedient nur einen Memorycontroller.

Bei dem Schaubild was ich kenne ist der zusätzliche Kommunikationskanal zwischen L2 und dem 2. Memory Controller eingezeichnet, nicht zwischen den Controllern.

http://images.anandtech.com/doci/8935/GTX970_ROP_575px.png



Man fragt sich auch, warum Nvidia erst das Interface kürzt, dann aber eine umständliche Methode einbauen sollte, doch irgendwie 256-Bit-Zugriff zu erlauben.

Nvidia hat extra, ein zusätzliches Interface eingebaut um genau diese 256bit mit deaktivierten ROPs zu ermöglichen, wie aufwändig das auch immer sein mag.

[Malabolge]

Bei dem Schaubild was ich kenne ist der zusätzliche Kommunikationskanal zwischen L2 und dem 2. Memory Controller eingezeichnet,
nicht zwischen den Controllern.
http://images.anandtech.com/doci/8935/GTX970_ROP_575px.png
Nvidia hat extra, ein zusätzliches Interface eingebaut um genau diese 256bit mit deaktivierten ROPs zu ermöglichen, wie aufwändig das auch immer sein mag.

Memorycontroller 1 an Level 2 : "Möchte jetzt Daten schicken !"
Level 2 ; "OK, Mach mal "

Memoryconroller 2 an Level 1 : "Ich will aber auch !"
Level 2 "Dieselbe Leitung ?"

Memorycontoller 2 " JA JA JA , Was der Darf darf ich auch !"
Level 2 : "Ne denn , wird ja wohl gehen , Schick Mal"

So oder so ähnlich müsste sich die Kommkunikation CHIP-Intern wohl abspielen, Müsste wohl mal jemand "lauschen"
Sicherlich wirst du aus den RAMs 256 bit Lesen aber was bringt das , wenn nur 224 bit Rauslaufen ?
Also erreicht das Speicherinterface (gesamter weg von RAM zu "Verbraucher")
im Gesamten NIE 256 bit, und wenn du noch 1024 und mehr bit aus dem RAM liest (Rosienenpickerei)
Es gehen nur 224 gleichzeitig durch den L2 und die Crossbar. ENGSTELLE !



PS : Im April kommt auch der liebe Osterhasi !

[Gast]

Man sollte sich solche Schaubilder dann mal genauer betrachten und sich fragen warum Jensen von einer 3GBVram Karte spricht. Sieht ja am graumelierten Hintergrund soaus als würden Bereiche zusammengefasst. So könnte es sein das an 64bit Controllern 1 GB angebunden werden und für NVidia die Möglichkeit besteht einen Teil dann auf 32bit zu reduzieren soweit etwas nicht die Spezifikationen einer 980 erfüllt. Dies scheint immer dann der Fall wenn der Chip nicht wie vorgesehen alle SMX nutzen kann. Das Schema mit den schönen Pfeilen lenkt einfach vom wesentlichen ab. Wahrscheinlich ist die Kate in Wirklichkeit eine 64bit+64bit+64bit+32bit Karte (ein teildeaktiierter 64bit Controllerblock!). Dann hätte sie tatsächlich nur 192bit+32bit mit 2x512mb Ram angebunden am teildeaktivierten Controller. NVidia verarscht die Leute auf hohem Niveau und macht sich dann seit gestern auch noch über sie lustig.

[aths]

Bei dem Schaubild was ich kenne ist der zusätzliche Kommunikationskanal zwischen L2 und dem 2. Memory Controller eingezeichnet, nicht zwischen den Controllern.

http://images.anandtech.com/doci/8935/GTX970_ROP_575px.pngJa, das habe ich falsch beschrieben. Der L2-Cache spricht den einen oder anderen Memorycontroller an. (Das ist funktionial zwar gleichwertig als würden diese untereinander kommunizieren, aber vom Datenfluss her falsch, da die Daten nicht erst in einen Memorycontroller reinfließen.)

Nvidia hat extra, ein zusätzliches Interface eingebaut um genau diese 256bit mit deaktivierten ROPs zu ermöglichen, wie aufwändig das auch immer sein mag.
Das stimmt trotzdem nicht. Das Bild zeigt auch den Flaschenhals. Die 970 hat zwar 256 Datenleitungen zum Speicher, kann diese aber nicht gleichzeitig benutzen.

[aths]

Man sollte sich solche Schaubilder dann mal genauer betrachten und sich fragen warum Jensen von einer 3GBVram Karte spricht. Sieht ja am graumelierten Hintergrund soaus als würden Bereiche zusammengefasst. So könnte es sein das an 64bit Controllern 1 GB angebunden werden und für NVidia die Möglichkeit besteht einen Teil dann auf 32bit zu reduzieren soweit etwas nicht die Spezifikationen einer 980 erfüllt. Dies scheint immer dann der Fall wenn der Chip nicht wie vorgesehen alle SMX nutzen kann. Das Schema mit den schönen Pfeilen lenkt einfach vom wesentlichen ab. Wahrscheinlich ist die Kate in Wirklichkeit eine 64bit+64bit+64bit+32bit Karte (ein teildeaktiierter 64bit Controllerblock!). Dann hätte sie tatsächlich nur 192bit+32bit mit 2x512mb Ram angebunden am teildeaktivierten Controller. NVidia verarscht die Leute auf hohem Niveau und macht sich dann seit gestern auch noch über sie lustig.
Die GTX 980M hat 12 aktive SMX, aber ein volles Speicherinterface.

[Gast]

Und die 970m?

Hast du schon ein Bild der SMM-Block Aufteilung von der 980m vs 970m zu Gesicht bekommen?

Scheint so, als hätte das SI mit der Anzahl der ROP Aufteilung zu tun und wäre zudem jeweils von der Blockaufteilung SMM vs. L2-MC abhängig, die verschweigen etwas. Möglich ist die 980m hat 4 SMM Blöcke a 3 Einheiten und nicht 4 a 4 wie in der einfachen 980-970 Schematik seitens NVidia. Also ist es gut möglich das die 980m genauso entworfen wurde und die 970m ist wieder ein teildeaktvierter Salvage-Part. Dann aber mit weniger L2-MC.

Bin mal auf die 950 gespannt sollte eine erscheinen. Glaube bald sowas wird nicht kommen. Die hätte dann wohl nur ein 96bit SI.

Der 28nm Prozess von Mawellv2 scheint sehr ergiebig und fehlerfrei zu sein so das NVidia die Einheiten und das SI beschneiden muss um Savalge-Parts auflegen zu können. Genau dafür hat man wohl auch Maxwell entwickelt, billiger geht es eigentlich nicht (Wafertechnisch) und man kann gut auf die Nachfrage reagieren, muss nicht warten bis der fehlerhafte Prozess genug Savalge-Parts abliefert.

Anders kann man das unsinnige Gequatsche von Jensen nicht werten. Ich kann mir trotzdem nicht vorstellen das man zulässt das ein Ceo oder etwas dergleichen von NVidia so einen Unsinn verbreitet. Definitiv klar ist mittlerweile, dass das pure Absicht ist und war; und NVidia deshalb offensichtlich bewusst gelogen hat, was das SI der 970 angeht. Eine interessante Entwicklung!

Im Übrigen haben sie einfach nur beteuert das dies bei der 970m-980m nicht so wäre, wer weiß schon was sie da bereits manipuliert haben, dass man dies gar nicht mehr feststellen-auslesen kann. (siehe die ehenalige Meldung zur MSI 970 "neues Bios", dies sollte dann als 256bit SI anstatt 224bit SI ausgelesen werden).

Ich hoffe irgend jemand guckt sich das mal an.

GM200-GM204-GM206 und den Rest einfach teildeaktviert. Schon komisch das der GM206 nicht für die 950m-960m erscheint?

Sehr eigenartig ist auch die Treiberseitige Beschneidung der OC-Feature bei Notebooks-dGPUs, diese wurden im Ausmaß (zulässige OC-Taktraten) vorher zwischen NVidia und dem jeweiligen Hersteller abgestimmt und an der jeweilgen Kühllösung des Notebooks spezifiziert-festgemacht (mit Zustimmung von NVidia). Irgendetwas ist dort im argen!!! Warum will man jetzt die Treiberseitige Funktion deaktivieren bzw. hat dies so gemacht? Das wäre doch völlig anders händelbar und auch mitteilbar gewesen.

Schon komisch das der GM200 seit Monaten fertig auf der Halde liegt und NVidia vor dem HBM SI seitens AMD einfach nur so die Kniee schlottern.

Denke mal der lässt sich genausogut teildeaktivieren oder nicht, dazu bräuchte man aber irgendein Zeichen seitens AMDs Fiji, dass man nicht hat.

Wirft man ihn jetzt zu sehr beschnitten auf den markt wird es eine Gurke der das ganze derzeitige Preiskonstrukt in die Hölle reissen könnte. Das zeigt mal wieder das NVidia nicht um den Spieler geht, sondern nur was man mit wenig Aufwand am meisten verdienen kann.

Einfach ein grottiger Laden, nach Jensen Kommentar nur noch lächerlich und Kiúndenverachtent. Die Verarsche war definitiv geplant. Pah...

[aths]

Die Zahl an vollständig implementierten ROPs sinkt bei der Deaktivierung von SMX. Das ist imo kein Beinbruch: Weniger SMX = weniger Rechenkraft = weniger Pixel, also braucht man auch nicht so viele ROPs.

Der verfügbare L2-Cache ist unabhängig von den SMX, da die SMX an die Crossbar gehen und diese erst zum L2.