3DCenter berichtet über angeblichen VRAM Fehler der 970

[Dr.Schneider]

Bei meiner Palit Jetstream GTX 970 selbes Bild.
besonders beunruigend: beim Ende des L2-Tests crasht der Treiber und das Bild wird schwarz?!
VRAM kaputt?

Spoiler

Nai's Benchmark, edited by VultureX
Device: GeForce GTX 970 (4.00 GB)
Memory Bus Width (bits): 256
Peak Theoretical DRAM Bandwidth (GB/s): 224.320000

Allocating Memory . . .
Chunk Size: 128 MiByte
Allocated 30 Chunks
Allocated 3840 MiByte

Benchmarking DRAM
DRAM-Bandwidth of Chunk no. 0 (0 MiByte to 128 MiByte):154.14 GByte/s
DRAM-Bandwidth of Chunk no. 1 (128 MiByte to 256 MiByte):154.09 GByte/s
DRAM-Bandwidth of Chunk no. 2 (256 MiByte to 384 MiByte):154.29 GByte/s
DRAM-Bandwidth of Chunk no. 3 (384 MiByte to 512 MiByte):154.08 GByte/s
DRAM-Bandwidth of Chunk no. 4 (512 MiByte to 640 MiByte):154.12 GByte/s
DRAM-Bandwidth of Chunk no. 5 (640 MiByte to 768 MiByte):154.27 GByte/s
DRAM-Bandwidth of Chunk no. 6 (768 MiByte to 896 MiByte):154.13 GByte/s
DRAM-Bandwidth of Chunk no. 7 (896 MiByte to 1024 MiByte):154.37 GByte/s
DRAM-Bandwidth of Chunk no. 8 (1024 MiByte to 1152 MiByte):154.12 GByte/s
DRAM-Bandwidth of Chunk no. 9 (1152 MiByte to 1280 MiByte):154.09 GByte/s
DRAM-Bandwidth of Chunk no. 10 (1280 MiByte to 1408 MiByte):154.36 GByte/s
DRAM-Bandwidth of Chunk no. 11 (1408 MiByte to 1536 MiByte):154.04 GByte/s
DRAM-Bandwidth of Chunk no. 12 (1536 MiByte to 1664 MiByte):154.40 GByte/s
DRAM-Bandwidth of Chunk no. 13 (1664 MiByte to 1792 MiByte):154.15 GByte/s
DRAM-Bandwidth of Chunk no. 14 (1792 MiByte to 1920 MiByte):154.09 GByte/s
DRAM-Bandwidth of Chunk no. 15 (1920 MiByte to 2048 MiByte):154.35 GByte/s
DRAM-Bandwidth of Chunk no. 16 (2048 MiByte to 2176 MiByte):154.10 GByte/s
DRAM-Bandwidth of Chunk no. 17 (2176 MiByte to 2304 MiByte):154.16 GByte/s
DRAM-Bandwidth of Chunk no. 18 (2304 MiByte to 2432 MiByte):154.42 GByte/s
DRAM-Bandwidth of Chunk no. 19 (2432 MiByte to 2560 MiByte):154.14 GByte/s
DRAM-Bandwidth of Chunk no. 20 (2560 MiByte to 2688 MiByte):154.37 GByte/s
DRAM-Bandwidth of Chunk no. 21 (2688 MiByte to 2816 MiByte):154.14 GByte/s
DRAM-Bandwidth of Chunk no. 22 (2816 MiByte to 2944 MiByte):154.09 GByte/s
DRAM-Bandwidth of Chunk no. 23 (2944 MiByte to 3072 MiByte):154.35 GByte/s
DRAM-Bandwidth of Chunk no. 24 (3072 MiByte to 3200 MiByte):22.19 GByte/s
DRAM-Bandwidth of Chunk no. 25 (3200 MiByte to 3328 MiByte):22.19 GByte/s
DRAM-Bandwidth of Chunk no. 26 (3328 MiByte to 3456 MiByte):22.19 GByte/s
DRAM-Bandwidth of Chunk no. 27 (3456 MiByte to 3584 MiByte):27.32 GByte/s
DRAM-Bandwidth of Chunk no. 28 (3584 MiByte to 3712 MiByte): 6.59 GByte/s
DRAM-Bandwidth of Chunk no. 29 (3712 MiByte to 3840 MiByte): 6.62 GByte/s
Benchmarking L2-Cache
L2-Cache-Bandwidth of Chunk no. 0 (0 MiByte to 128 MiByte):425.99 GByte/s
L2-Cache-Bandwidth of Chunk no. 1 (128 MiByte to 256 MiByte):426.16 GByte/s
L2-Cache-Bandwidth of Chunk no. 2 (256 MiByte to 384 MiByte):425.92 GByte/s
L2-Cache-Bandwidth of Chunk no. 3 (384 MiByte to 512 MiByte):426.06 GByte/s
L2-Cache-Bandwidth of Chunk no. 4 (512 MiByte to 640 MiByte):425.89 GByte/s
L2-Cache-Bandwidth of Chunk no. 5 (640 MiByte to 768 MiByte):426.14 GByte/s
L2-Cache-Bandwidth of Chunk no. 6 (768 MiByte to 896 MiByte):426.11 GByte/s
L2-Cache-Bandwidth of Chunk no. 7 (896 MiByte to 1024 MiByte):426.21 GByte/s
L2-Cache-Bandwidth of Chunk no. 8 (1024 MiByte to 1152 MiByte):426.07 GByte/s
L2-Cache-Bandwidth of Chunk no. 9 (1152 MiByte to 1280 MiByte):425.94 GByte/s
L2-Cache-Bandwidth of Chunk no. 10 (1280 MiByte to 1408 MiByte):426.04 GByte/s
L2-Cache-Bandwidth of Chunk no. 11 (1408 MiByte to 1536 MiByte):426.12 GByte/s
L2-Cache-Bandwidth of Chunk no. 12 (1536 MiByte to 1664 MiByte):426.14 GByte/s
L2-Cache-Bandwidth of Chunk no. 13 (1664 MiByte to 1792 MiByte):426.01 GByte/s
L2-Cache-Bandwidth of Chunk no. 14 (1792 MiByte to 1920 MiByte):426.11 GByte/s
L2-Cache-Bandwidth of Chunk no. 15 (1920 MiByte to 2048 MiByte):426.14 GByte/s
L2-Cache-Bandwidth of Chunk no. 16 (2048 MiByte to 2176 MiByte):426.16 GByte/s
L2-Cache-Bandwidth of Chunk no. 17 (2176 MiByte to 2304 MiByte):426.07 GByte/s
L2-Cache-Bandwidth of Chunk no. 18 (2304 MiByte to 2432 MiByte):426.11 GByte/s
L2-Cache-Bandwidth of Chunk no. 19 (2432 MiByte to 2560 MiByte):426.10 GByte/s
L2-Cache-Bandwidth of Chunk no. 20 (2560 MiByte to 2688 MiByte):426.10 GByte/s
L2-Cache-Bandwidth of Chunk no. 21 (2688 MiByte to 2816 MiByte):426.20 GByte/s
L2-Cache-Bandwidth of Chunk no. 22 (2816 MiByte to 2944 MiByte):426.18 GByte/s
L2-Cache-Bandwidth of Chunk no. 23 (2944 MiByte to 3072 MiByte):425.89 GByte/s
L2-Cache-Bandwidth of Chunk no. 24 (3072 MiByte to 3200 MiByte):75.73 GByte/s
L2-Cache-Bandwidth of Chunk no. 25 (3200 MiByte to 3328 MiByte):75.73 GByte/s
L2-Cache-Bandwidth of Chunk no. 26 (3328 MiByte to 3456 MiByte):75.73 GByte/s
L2-Cache-Bandwidth of Chunk no. 27 (3456 MiByte to 3584 MiByte):92.36 GByte/s
Kernel launch failed: the launch timed out and was terminated
Kernel launch failed: the launch timed out and was terminated
Drücken Sie eine beliebige Taste . . .

 

[Zucksi]

Ist bei mir mit der 780 Ti aber genauso

Wenn ich allocation auf 3 GB stelle gibts auch den Blackscreen und der Treiber wird zurückgesetzt

 

[poi]

NVidia Stellungnahme.

http://www.pcper.com/news/Graphics-Cards/NVIDIA-Responds-GTX-970-35GB-Memory-Issue

Jedoch irgendwie nur an pcper rausgegangen, kA was man davon halten soll.

Edit:
http://techreport.com/news/27721/nvidia-admits-explains-geforce-gtx-970-memory-allocation-issue

techreport hats auch veröffentlicht.

 

[BookerDeWitt]

Naja, das klingt schön wenn nVidia mit ein paar Benchmarks beweisen möchte, dass es keinen Unterschied in der Performance zwischen einer 970 und 980 gibt sobald ein Spiel mehr als die 3,5GB benötigt. Aber die 970-User wurden ja nicht auf den 3,5GB-VRam-Bug dadurch aufmerksam, dass die Performance einbricht, sondern dadurch, dass es bei mehr als 3,5GB-VRam-Gebrauch zu heftigen Nachladerucklern kommt.

Diese kann man ja schliesslich nicht in FPS-Zahlen sehen. Also lässt sich wohl eher sagen, dass eine 970 nur mit 3,5GB-VRambelegung effektiv umgehen kann. Alles darüber ist nicht mehr adäquat nutzbar. Die 980 hingegen kommt auch mit 4GB-Belegung zurecht. Also ist die 970 wohl eher eine 4GB Mogelpackung
Ich kann auch kaum glauben, dass nVidia davon nichts wusste. Aber im Marketing klingt 4GB insgesamt besser als 3,5GB effektiv (dann wäre man ja immer noch/ schon wieder schlechter als die Konkurrenz ). Aber ich wette dieser "Bug" verschwindet genauso schnell wieder in der Schublade wie das Spulenfiepen der 970er

 

[gmc]

RAM Mangel hat sich nie unbedingt an den fps ablesen lassen können. Bei Microruckeln sieht man das nicht in Benchmarks, höchstens in frametime Messungen. Immerhin hat Nvidia es zugegeben. Ein Bug ist es somit nicht, was immer unwahrscheinlich erschien.

 

[vidarv]

Selbe Problem gibt es ürbigens auch bei der GTX 760!

 

[gmc]

Selbe Problem gibt es ürbigens auch bei der GTX 760!
Anhang anzeigen 469828

Falsche Messung ist wahrscheinlicher.

 

[hübie]

Bestätigte ja weitgehend meine Vermutung. Man kann es per Treiber nicht völlig umgehen, aber mildern. Das werden die auch machen.

 

[Sontin]

Interessant wäre es zu wissen, ob man per Cuda auch an das zweite Segment heran kommt.

 

[Dai6oro]

Starkes Stück, das !!! haben die sich also seit den ersten Anfragen vor über 1 Woche überlegt zu antworten. Nicht deren ernst oder?
die haben echt geglaubt es merkt keiner.

 

[Fragesteller]

Nun sollten es alle wissen und ich bin gespannt wie viele 970er User am Mo. ihren Händler anrufen.

 

[smilefaker]

Sowie beim Directx11.1 Unsinn, jetzt der " ich verkaufe 4GB, aber die letzten 20% des Rams sind unbrauchbar, aber geht schon oder?" Unsinn.
Lächerlich.

 

[Pisaro]

Wirklich lächerlich das ganze. Nen Kollege von mir wollte sich ne 970 holen, werde ihn jetzt aber davon abraten.

 

[t3chn0]

Was mich so stutzig macht....warum berichten auf einmal auch 780er, 780Ti und 760er User über die gleiche Problematik? Existiert dieses Problem vielleicht schon seit Jahren und keiner hat es bemerkt?

Ab und an wurde mal über Nachladeruckler geschrieben. Das wurde aber einfach auf den vollen Speicher geschoben.

 

[Nai]

Bei meiner Palit Jetstream GTX 970 selbes Bild.
besonders beunruigend: beim Ende des L2-Tests crasht der Treiber und das Bild wird schwarz?!
VRAM kaputt?

Das ist der Watch-Dog von Windows, weil das Benchmark unter umständen zu lange brauchen kann. Siehe:
http://stackoverflow.com/questions/...after-several-seconds-how-to-work-around-this

Interessant wäre es zu wissen, ob man per Cuda auch an das zweite Segment heran kommt

Wenn die GPU den Speicher ähnlich wie in DirectX allozieren sollte, dann sind es circa die letzten 500 MiB, bevor der erste Einbruch auftritt.


Und nachdem ich jetzt nach circa 13 Stunden ausgeschlafen bin gibt es eine ausführliche Erklärung dazu . Ich bin mir allerdings stellenweise etwas unsicher, da NVIDIA das ganze nicht 100 \% dokumentiert, oder ob man die Erklärung als nicht-Informatiker so 100 \% versteht, versuche es aber mal dennoch. Kritik und Fragen sind aber willkommen.

Das Benchmark misst "eigentlich" nicht die DRAM-Bandbreite, sondern die Bandbreite des "global Memory"s in CUDA. Der global Memory in CUDA ist ein virtueller Speicherraum, welcher nicht nur den DRAM der GPU sondern auch DRAM-Bereiche der CPU umfasst. Ein virtueller Speicherraum zeichnet sich immer dadurch aus, dass es virtuelle Speicheraddressen gibt. Die virtuellen Speicheraddressen werden bei einem Speicherzugriff *irgendwie* in die eigentlichen physikalischen Speicheraddressen des DRAMs übersetzt. Der Vorteil an einem solchen virtuellem Speicherraum ist unter anderem, dass er ein Auslagern von Speicherbereichen ermöglicht. Eben ein solches Auslagern in den DRAM der CPU scheint CUDA hier in dem Benchmark bei den Einbrüchen zu machen.

Das Benchmark alloziert sich so viele Blöcke des global Memorys innerhalb des DRAMs der GPU wie möglich. Anschließend misst es die Lesebandbreite innerhalb jedes einzelnen dieser Blöcke. Die Messung geht nur so lange wie sich die allozierten Blöcke auch wirklich in dem DRAM der GPU befinden gut. In diesem Fall wird die Speicherbandbreite relativ genau gemessen.

Problematisch ist allerdings, dass das Benchmark den DRAM der GPU nicht komplett für sich besitzt. Denn im Hintergrund laufen Windows und diverse Programme, die alle ebenfalls etwas vom DRAM der GPU beanspruchen. Der virtuelle Speicherraum garantiert dem Benchmark jedoch, dass es fast die kompletten 4 GiByte (abgesehen von dem Bereich der primary Surface(?)) für sich verwenden darf. Deshalb schlägt die Allozierung von DRAM zunächst bis zur Obergrenze von in etwa 4 GiByte nicht fehl. Allerdings muss die GPU nun anfangen Speicherbereiche zu swappen. Das heißt, wenn die CUDA Anwendung läuft, sollten im DRAM der GPU die entsprechenden Daten der CUDA-Anwendung liegen. Läuft der Zeichenvorgang von Windows oder einer anderen Anwendung sollten sich im DRAM der GPU ihre Daten befinden.

Die GPU scheint das Swappen, gemäß meinen ersten einfachen Untersuchungen dieses Benchmarks, einfach assoziativ zu machen. Das heißt an einer physikalsichen Addresse in dem GPU-DRAM müssen sich immer die selben CUDA-Daten oder DirectX-Daten befinden. Dadurch kommt es zu Konflikten, die sich in dem Einbruch der Bandbreite des global Memorys in solchen Konfliktbereichen äußern.

Das Benchmark versucht diesen Effekt zu reduzieren, indem es die Daten in jedem Speicherbereich mehrmals nacheinander anfordert. Das heißt beim ersten Anfordern "sollte" das Benchmark einen Page-Fault verursachen. Bei dem Page-Fault "sollte" die GPU die Daten der Page von dem DRAM der CPU aus in den DRAM der GPU kopieren. Dann würden die weiteren globalen Speicherzugriffe mit der DRAM-Bandbreite ausgeführt werden. So zumindest die Annahme meinerseits.

Interessantweise verhält sich die GPU nicht so wie von mir erwartet. So scheint die GPU bei einem Page-Fault in CUDA die entsprechenden Daten nicht in den DRAM der GPU hochzuladen, sondern bei jedem Speicherzugriff erneut direkt aus dem DRAM der CPU anzufordern. Dadurch misst das Benchmark insgesamt in solchen Fällen mehr oder weniger das Swapping-Verhalten von CUDA und nicht die DRAM-Bandbreite.

Das ganze lässt sich auch leicht verifizieren, indem man irgendwelche Anwendungen im Hintergrund laufen lässt, die viel DRAM von der GPU beanspruchen, wodurch mehr Swapping stattfinden muss. In diesem Fall bricht das Benchmark auch ein.

 

[t3chn0]

Mal abgesehen davon, dass ich dich liebe.... warum tritt dieses Phänomen dann bei den 980ern nicht auf? Warum haben es aber die 7er Karten scheinbar auch?

Würde sich etwas ändern, wenn man die Frequenz des DRAMs massiv erhöht , bzw. reduziert? Dies sollte doch direkte Auswirkungen auf die Bandbreite zeigen, oder nicht?

 

[Mark3Dfx]

Wäre mal an der Zeit für ein Statement der Reviewer zu diesem "unbekannten" neuen Feature der 980/970/960(?) Karten

 

[poi]

https://forums.geforce.com/default/...tx-970-3-5gb-vram-issue/post/4432672/#4432672

Damit sind die bei techreport und pcper veröffentlichten Statements offiziell

 

[KenshiHH]

Also wurden wir 970er besitzer ganz klar beschissen und getäuscht, haben nur effektive 3,5gb VRam da die letzten 512mb nur zur schönung auf der verpackung/daten vorhanden sind.

 

[And.!]

Es steht doch noch nichts zu 100% fest. Womöglich hatte Nvidia den schnellen Weg genommen und den Treiber/die Firmware nicht richtig auf den kastrierten Chip angepasst. Es hat ja auch eine Weile funktioniert bis es "aufgeflogen" ist. Die GTX970 ist ja auch nicht die erste Konfiguration mit vollem Speicherinterface und beschnittenem Chip, wenn ich mich nicht irre. Die Tests zeigen doch, dass u.U. auch ohne Geschwindigkeitseinbuße auf die letzten 512MB zugegriffen werden kann.
Ohne noch genauere Untersuchungen kann man weder das eine, noch das andere belegen.
Jetzt wird schon Hynix beschuldigt an diesem "Problem" Schuld zu sein, da angeblich Samsung GDDR5 Ram nicht von diesem Problem betroffen ist. Bis jetzt reine Spekulationen. Wer auf Nummer sicher gehen will, sollte natürlich mit dem Kauf warten. So riskiert man höchstens ein paar Tage bis Wochen Wartezeit.

Vielleicht kann einer der betroffenen Tester mal nur einen Ram Riegel (Single Channel) einbauen und den Ramtakt so weit es geht senken. Das müsste sofort als noch niedrigere Bandbreite im betroffenen VRAM Bereich zu merken sein. Denn den Swap-Vorgang konnte bis jetzt noch nicht zu 100% bewiesen werden, wenn ich alles richtig verstanden habe.

Edit: Die Betroffenen könnten auch den Speicherhersteller auf der Karte angeben. Vielleicht ist an der Behauptung mit Hynix ja doch was dran.