3DCenter berichtet über angeblichen VRAM Fehler der 970

[gmc]

Ich hatte von DDR3-2133 auf DDR3-1600 gestellt, am Ergebnis hat sich nichts geändert.

 

[Tafelzwerk]

Nachdem das Verhalten von NVIDIA bestätigt wurde, stellt sich nun die Frage, wie wir damit umgehen sollen.

a) Damit leben und fertig?
b) Hoffen und drängen, dass diesbezüglich eine Lösung gefunden wird (Treiber, BIOS, Umtausch)?
c) Händler oder Hersteller direkt anschreiben und um Austausch bitten?
d) Weiter auf NVIDIA zugehen und ggf. rechtliche Schritte einleiten (ehrlich gesagt nicht meine Intention)?

 

[t3chn0]

Ich habe auf meiner 970er Samsung Speicher und das Problem trotzdem.

Wie sieht das aus mit der L2 Cache Geschichte?

Bei manchen wurden 2MB angezeigt, bei anderen nur 1.7MB (so wie bei mir auch).

 

[Zotac2012]

Edit: Bei meiner Recherche zu den verschiedenen Grafikkarten der GTX 970 Reihe bin ich unter anderem auf der Homepage von Gigabyte unter der Gigabyte GTX 970 GV-N970G1 GAMING-4GD (rev. 1.0/1.1) auf folgenden Satz gestoßen der wie folgt lautet:
* Aufgrund der Standard-PC-Architektur ist ein Teil des Speichers für die Nutzung des Systems reserviert und daher kann die aktuelle Speichergröße von der Speicherangabe abweichen.

Heißt das jetzt, das die GTX 970 in diesem Fall z.B. von Gigabyte deshalb nur 3,5 GB Vram voll ausnutzen kann da die Restlichen 0,5 GB dem PC-System zur Verfügung stehen und daher dann die FPS einbrüche bzw. nachladeruckler entstehen ? Und was genau stellt dieser Vram dann dem PC-System mit diesen 0,5 GB zur Verfügung, d.h was im System nutzt dann diesen Vramspeicher ?

Antwort von User hübie:

Das bezieht sich wohl eher darauf dass sich Windows etwas genehmigt und dass Adressraum für Transfers reserviert wird. War bei PCI schon so.

Das ist doch eigentlich genau das was Nvidia jetzt hier nochmals betätigt hat, im Umkehrschluß bedeutet das einfach man hat eine Nvidia GTX 970 mit 4GB/Vram von denen man 3,5GB Vram mit voller Speicheranbindung nutzen kann und die restlichen 0,5 GB/Vram können nur noch so schnell verarbeitet werden, wie es das System nach Abzug der restlichen Systemanwendungen im Vram dies zuläßt. Wenn das schon seit PCI bekannt war dann sollte man sich aber auch jetzt nicht aufregen, Oder doch?

Aber selbst mit 3,5GB/Vram werde ich dennoch eine GTX 970 kaufen demnächst, da mir die Leistung zusagt und es immer noch 1,5 GB/Vram mehr ist, als das bei meiner jetzigen HD 7870 GHz der Fall ist.

 

[Tafelzwerk]

Lirum Larum, die Frage resultiert u.a. daraus, warum sich das System bei der 980 GTX anders verhält. Betrachte das hier immer im Vergleich zur 980 GTX. Warum reserviert die 980e den kompletten VRAM während der Spiele? Daher kann es sich um kein PCI-Problem handeln, sondern um ein spezifisches 970 GTX Problem.

Rein aus Sicht FPS pro Sekunde scheint es hier ja wirklich kein Problem zu geben, siehe NVIDIAs Statement. Betrachten wir nun individuelle Nachladeruckler, muss bislang festgestellt werden, dass scheinbar seitens 970 GTX Probleme vorliegen. Diese lassen sich aber nicht in Form von Durchschnitts-FPS beweisen.

 

[Zotac2012]

@Tafelzwerk
Entweder es liegt an der Optimierung im Treiber, das die GTX 980 das mit dem Vram besser bewältigt oder es liegt an den fehlenden Stream Prozessoren der GTX 970, denn die Speicheranbindung ist ja mit 256 Bit bei beiden Grafikkarten gleich.

 

[Tafelzwerk]

Wie NVIDIA ja selber schreibt, arbeiten die Streaming Prozessoren anders als bei der 980. Es sind ja auch drei weniger verfügbar. Da verzichtet die Karte eben lieber auf die volle Auslastung des VRAMS, und swappt. Die Frage, die wir nicht beantworten können: warum entschied man sich bei NVIDIA für diesen Weg?

a) Weil es tatsächlich performanter ist, als auf die stetige Verwendung des VRAMS zu setzen?

b) Weil NVIDIA die 970 besser zur 980 platzieren wollte? Zum Zeitpunkt der Veröffentlichung der 970 gab es mit der 750Ti ein preiswertes Modell im Portfolio sowie mit der 980 GTX ein vorläufiges HighEnd-Modell. Es macht wirtschaftlich Sinn, die Karte genau mittig zu positionieren. NVIDIA hat aber vermutlich unterschätzt, dass das tatsächlich Konsequenzen haben könnte.

c) Auch nicht so abwegig: eventuell würde es gar keinen Unterschied machen, ob die Karte nun 4 Gigabyte oder 3,5 zieht. Und aus Effizienzgründen bevorzugt die Karte in selber Umgebung lieber die effiziente Variante und alloziert 3,5 GB. In Fällen, wo es tatsächlich zum Stuttering kommt, würde es auch mit 4 GB zu Stuttering kommen. Die User sehen eventuell nur, was sie sehen möchte. Eine Karte, die absolut am Limit ist. Unglücklicherweise ist der VRAM nur noch nicht voll belegt, was eventuell irrtümlicherweise den Verdacht schöpft, dass noch Potenzial vorhanden ist. Was nun, wenn das schlichtweg eine falsche Annahme ist? Vielleicht erfahren wir das noch ...

 

[pturn]

Hey Leute, hier mal der Benchmark mit einer EVGA GTX 980 SC.

Nai's Benchmark
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):177.38 GByte/s
DRAM-Bandwidth of Chunk no. 1 (128 MiByte to 256 MiByte):177.44 GByte/s
DRAM-Bandwidth of Chunk no. 2 (256 MiByte to 384 MiByte):177.55 GByte/s
DRAM-Bandwidth of Chunk no. 3 (384 MiByte to 512 MiByte):177.73 GByte/s
DRAM-Bandwidth of Chunk no. 4 (512 MiByte to 640 MiByte):177.65 GByte/s
DRAM-Bandwidth of Chunk no. 5 (640 MiByte to 768 MiByte):177.44 GByte/s
DRAM-Bandwidth of Chunk no. 6 (768 MiByte to 896 MiByte):177.58 GByte/s
DRAM-Bandwidth of Chunk no. 7 (896 MiByte to 1024 MiByte):177.25 GByte/s
DRAM-Bandwidth of Chunk no. 8 (1024 MiByte to 1152 MiByte):177.76 GByte/s
DRAM-Bandwidth of Chunk no. 9 (1152 MiByte to 1280 MiByte):177.56 GByte/s
DRAM-Bandwidth of Chunk no. 10 (1280 MiByte to 1408 MiByte):177.64 GByte/s
DRAM-Bandwidth of Chunk no. 11 (1408 MiByte to 1536 MiByte):177.64 GByte/s
DRAM-Bandwidth of Chunk no. 12 (1536 MiByte to 1664 MiByte):177.76 GByte/s
DRAM-Bandwidth of Chunk no. 13 (1664 MiByte to 1792 MiByte):177.56 GByte/s
DRAM-Bandwidth of Chunk no. 14 (1792 MiByte to 1920 MiByte):177.57 GByte/s
DRAM-Bandwidth of Chunk no. 15 (1920 MiByte to 2048 MiByte):177.73 GByte/s
DRAM-Bandwidth of Chunk no. 16 (2048 MiByte to 2176 MiByte):177.70 GByte/s
DRAM-Bandwidth of Chunk no. 17 (2176 MiByte to 2304 MiByte):177.72 GByte/s
DRAM-Bandwidth of Chunk no. 18 (2304 MiByte to 2432 MiByte):177.56 GByte/s
DRAM-Bandwidth of Chunk no. 19 (2432 MiByte to 2560 MiByte):177.70 GByte/s
DRAM-Bandwidth of Chunk no. 20 (2560 MiByte to 2688 MiByte):177.60 GByte/s
DRAM-Bandwidth of Chunk no. 21 (2688 MiByte to 2816 MiByte):177.76 GByte/s
DRAM-Bandwidth of Chunk no. 22 (2816 MiByte to 2944 MiByte):177.52 GByte/s
DRAM-Bandwidth of Chunk no. 23 (2944 MiByte to 3072 MiByte):177.66 GByte/s
DRAM-Bandwidth of Chunk no. 24 (3072 MiByte to 3200 MiByte):177.69 GByte/s
DRAM-Bandwidth of Chunk no. 25 (3200 MiByte to 3328 MiByte):177.71 GByte/s
DRAM-Bandwidth of Chunk no. 26 (3328 MiByte to 3456 MiByte):177.52 GByte/s
DRAM-Bandwidth of Chunk no. 27 (3456 MiByte to 3584 MiByte):16.14 GByte/s
DRAM-Bandwidth of Chunk no. 28 (3584 MiByte to 3712 MiByte): 6.63 GByte/s
DRAM-Bandwidth of Chunk no. 29 (3712 MiByte to 3840 MiByte):10.64 GByte/s
Benchmarking L2-Cache
L2-Cache-Bandwidth of Chunk no. 0 (0 MiByte to 128 MiByte):559.24 GByte/s
L2-Cache-Bandwidth of Chunk no. 1 (128 MiByte to 256 MiByte):559.32 GByte/s
L2-Cache-Bandwidth of Chunk no. 2 (256 MiByte to 384 MiByte):559.15 GByte/s
L2-Cache-Bandwidth of Chunk no. 3 (384 MiByte to 512 MiByte):559.29 GByte/s
L2-Cache-Bandwidth of Chunk no. 4 (512 MiByte to 640 MiByte):559.04 GByte/s
L2-Cache-Bandwidth of Chunk no. 5 (640 MiByte to 768 MiByte):559.26 GByte/s
L2-Cache-Bandwidth of Chunk no. 6 (768 MiByte to 896 MiByte):559.24 GByte/s
L2-Cache-Bandwidth of Chunk no. 7 (896 MiByte to 1024 MiByte):559.09 GByte/s
L2-Cache-Bandwidth of Chunk no. 8 (1024 MiByte to 1152 MiByte):559.42 GByte/s
L2-Cache-Bandwidth of Chunk no. 9 (1152 MiByte to 1280 MiByte):559.36 GByte/s
L2-Cache-Bandwidth of Chunk no. 10 (1280 MiByte to 1408 MiByte):559.23 GByte/s
L2-Cache-Bandwidth of Chunk no. 11 (1408 MiByte to 1536 MiByte):559.18 GByte/s
L2-Cache-Bandwidth of Chunk no. 12 (1536 MiByte to 1664 MiByte):559.29 GByte/s
L2-Cache-Bandwidth of Chunk no. 13 (1664 MiByte to 1792 MiByte):559.36 GByte/s
L2-Cache-Bandwidth of Chunk no. 14 (1792 MiByte to 1920 MiByte):559.31 GByte/s
L2-Cache-Bandwidth of Chunk no. 15 (1920 MiByte to 2048 MiByte):559.13 GByte/s
L2-Cache-Bandwidth of Chunk no. 16 (2048 MiByte to 2176 MiByte):559.44 GByte/s
L2-Cache-Bandwidth of Chunk no. 17 (2176 MiByte to 2304 MiByte):559.24 GByte/s
L2-Cache-Bandwidth of Chunk no. 18 (2304 MiByte to 2432 MiByte):559.26 GByte/s
L2-Cache-Bandwidth of Chunk no. 19 (2432 MiByte to 2560 MiByte):559.16 GByte/s
L2-Cache-Bandwidth of Chunk no. 20 (2560 MiByte to 2688 MiByte):559.26 GByte/s
L2-Cache-Bandwidth of Chunk no. 21 (2688 MiByte to 2816 MiByte):559.24 GByte/s
L2-Cache-Bandwidth of Chunk no. 22 (2816 MiByte to 2944 MiByte):559.07 GByte/s
L2-Cache-Bandwidth of Chunk no. 23 (2944 MiByte to 3072 MiByte):559.26 GByte/s
L2-Cache-Bandwidth of Chunk no. 24 (3072 MiByte to 3200 MiByte):559.31 GByte/s
L2-Cache-Bandwidth of Chunk no. 25 (3200 MiByte to 3328 MiByte):559.15 GByte/s
L2-Cache-Bandwidth of Chunk no. 26 (3328 MiByte to 3456 MiByte):559.32 GByte/s
L2-Cache-Bandwidth of Chunk no. 27 (3456 MiByte to 3584 MiByte): 8.20 GByte/s
L2-Cache-Bandwidth of Chunk no. 28 (3584 MiByte to 3712 MiByte): 6.42 GByte/s
L2-Cache-Bandwidth of Chunk no. 29 (3712 MiByte to 3840 MiByte):10.46 GByte/s
Drücken Sie eine beliebige Taste . . .

System: I7 2600K, 16 GB Ram 2133, Win 8.1

Ergänzung (25. Januar 2015)

Nach einigen Benchmark-Durchläufen komme ich nun auch zur Vermutung dass das OS einiges am VRAM Dynamisch reserviert.
Nachdem ich mal einige Programme und laufende Prozesse geschlossen habe sah es so aus (nur die letzten Zeilen):

DRAM-Bandwidth of Chunk no. 26 (3328 MiByte to 3456 MiByte):177.60 GByte/s
DRAM-Bandwidth of Chunk no. 27 (3456 MiByte to 3584 MiByte):177.77 GByte/s
DRAM-Bandwidth of Chunk no. 28 (3584 MiByte to 3712 MiByte):177.74 GByte/s
DRAM-Bandwidth of Chunk no. 29 (3712 MiByte to 3840 MiByte): 6.64 GByte/s

L2-Cache-Bandwidth of Chunk no. 26 (3328 MiByte to 3456 MiByte):559.29 GByte/s
L2-Cache-Bandwidth of Chunk no. 27 (3456 MiByte to 3584 MiByte):16.17 GByte/s
L2-Cache-Bandwidth of Chunk no. 28 (3584 MiByte to 3712 MiByte): 8.20 GByte/s
L2-Cache-Bandwidth of Chunk no. 29 (3712 MiByte to 3840 MiByte):559.28 GByte/s
Drücken Sie eine beliebige Taste . . .

Vielleicht hilft es Euch.

 

[Zotac2012]

@pturn

Und was sehen wir da, ab 3,5 GB/Vram [jeweils die letzten drei Chunks] bricht auch hier bei der GTX 980 die Leistung von 177/559 GB auf 10 GB bzw. darunter ein, was ja dann eigentlich nur zeigt das dies nicht allein nur bei der GTX 970 so ist. Was dann allerdings die Frage aufwirft, warum es dann laut Aussagen der User bei der GTX 980 nicht auch zu nachladerucklern kommt, wie bei der GTX 970 ?

 

[pturn]

@Zotac2012

Schau mal meine Ergänzung an. Nachdem ich einige Prozesse geschlossen hatte gab es auch andere Ergebnisse. Ich denke hier spielt Windows mit (zumindest bei diesem Benchmark).

Ergänzung (25. Januar 2015)

Es gibt einen direkten Zusammenhang bei mir mit Chrome. Chrome nutzt zb VRAM.

 

[hübie]

Antwort von User hübie:


Das ist doch eigentlich genau das was Nvidia jetzt hier nochmals betätigt hat, im Umkehrschluß bedeutet das einfach man hat eine Nvidia GTX 970 mit 4GB/Vram von denen man 3,5GB Vram mit voller Speicheranbindung nutzen kann und die restlichen 0,5 GB/Vram können nur noch so schnell verarbeitet werden, wie es das System nach Abzug der restlichen Systemanwendungen im Vram dies zuläßt. Wenn das schon seit PCI bekannt war dann sollte man sich aber auch jetzt nicht aufregen, Oder doch?

Aber selbst mit 3,5GB/Vram werde ich dennoch eine GTX 970 kaufen demnächst, da mir die Leistung zusagt und es immer noch 1,5 GB/Vram mehr ist, als das bei meiner jetzigen HD 7870 GHz der Fall ist.

Du verwechselst da etwas. Das was auf der Gigabyte-homepage steht bezieht sich ausschließlich auf die Belegung von Speicherbereichen durch das OS. Da steht nichts von Bandbreite o.ä.

Lirum Larum, die Frage resultiert u.a. daraus, warum sich das System bei der 980 GTX anders verhält. Betrachte das hier immer im Vergleich zur 980 GTX. Warum reserviert die 980e den kompletten VRAM während der Spiele? Daher kann es sich um kein PCI-Problem handeln, sondern um ein spezifisches 970 GTX Problem.

Rein aus Sicht FPS pro Sekunde scheint es hier ja wirklich kein Problem zu geben, siehe NVIDIAs Statement. Betrachten wir nun individuelle Nachladeruckler, muss bislang festgestellt werden, dass scheinbar seitens 970 GTX Probleme vorliegen. Diese lassen sich aber nicht in Form von Durchschnitts-FPS beweisen.

PCI sowie so nicht. Und wie ich bereits sagte ist es auch kein Problem mit PCI (Express). Bitte nicht die Dinge aus dem Kontext reißen.

@Tafelzwerk
Entweder es liegt an der Optimierung im Treiber, das die GTX 980 das mit dem Vram besser bewältigt oder es liegt an den fehlenden Stream Prozessoren der GTX 970, denn die Speicheranbindung ist ja mit 256 Bit bei beiden Grafikkarten gleich.

So einfach ist das nicht.

 

[Zotac2012]

@hübie
Aber wenn wie z.B. auf der Gigabyte Seite steht, das ein Teil des Speicher [und das bezieht sich ja auf den Vram der Graka] dem PC-System zur Verfügung gestellt wird [und gehen wir mal davon aus das es sich dabei um diese 0,5 GB handelt wie es auch Nvidia bestätigt hat] dann wirkt sich das doch sehr wohl auf die Bandbreite aus, das sieht man doch auch in den Benches, da durch die PC-Systembelegung des Vrams nicht mehr die volle Bandbreitengeschwindigkeit zur Verfügung steht und so die Übertragungsrate rapide absinkt.

Und wenn es bei der GTX 980 zu keinen nachladerucklern kommt, es handelt sich hierbei ja um den gleichen Chip wie bei der GTX 970 der ja nur durch die Streamprozessoren beschnitten ist, dann kann es doch nur an der Treiberoptimierung oder an den fehlenden Streams liegen, das liegt doch nahe.

Es sei denn das es wirklich so ist, das bei den DDR5 Ram von Samsung dieses Problem nicht auftritt und nur die DDR5 Ram von Hynix betroffen sind, dann könnte es auch ein Hardwareproblem sein, was allerdings bis jetzt ja noch gar nicht bestätigt ist.

 

[hübie]

Herr je. Nein. Das was da steht hat Null Komma Null mit der Problematik die hier diskutiert wird zu tun.

"Windows" kann mit voller Bandbreite einen Bereich belegen der dann anderen Programmen nicht zugänglich ist welche dann den Host-memory nutzen müssen was in ~20 GB/s resultiert.

@Nai: Soviel mir bekannt ist kann man in CUDA sagen es soll nur device memory verwendet werden. War glaub ich CU_MEMTYPE_DEVICE.

 

[smilefaker]

Wieso schreibt dazu kein Redakteur eine News?

 

[poi]

Erstmal Nai vielen Dank für deine Arbeit!
Jetzt habe ich eine Frage.
So wie ich das verstehe versucht dein Benchmark den RAM der GPU zu nutzen was auch gut geht bis es bereits in Benutzung befindliche Bereiche beschreiben will. Dann *sollte* durch mehrmaliges anfragen die Daten des belegten RAM der GPU woanders (System RAM?) reingeschrieben werden um Platz für den Benchmark zu schaffen? Oder war es umgekehrt, der Belegte GPU RAM wird nicht freigegeben und CUDA schreibt daher in den System RAM?

Wie auch immer, die Daten für den Benchmark werden geschrieben. Das heißt einfach: Wenn ich den Benchmark im Headless betrieb durchführe sollte der GPU RAM leer sein und der komplette RAM verfügbar, also testbar sein. Wenn es nicht so ist schreibt dein Benchmark die Daten jedoch trotz allem in den System RAM.

Das heißt im Endeffekt wenn beim testen im headless Betrieb (also der GPU nicht als Bildausgabe) der System RAM (im Taskmanager sichtbar) beschrieben wird ist der GPU RAM nicht nutzbar.

 

[Dionysos808]

Der Air Boss Kühler kommt jetzt ohne 50-mm-Lüfter!

Viel interessanter als dieser Mangel, oder etwa nicht?

 

[rico007]

Der Air Boss Kühler kommt jetzt ohne 50-mm-Lüfter!

Viel interessanter als dieser Mangel, oder etwa nicht?

Nicht wirklich.
Nvidia bewirbt eine Grafikkarte die statt 4GB nur 3,5GB mit voller Geschwindigkeit adressieren kann. Genau genommen ein Betrug am Kunden.

 

[AMINDIA]

Wegen dem Problem wird es wohl auch keine 8GB Version geben.

 

[Tafelzwerk]

@pturn

Und was sehen wir da, ab 3,5 GB/Vram [jeweils die letzten drei Chunks] bricht auch hier bei der GTX 980 die Leistung von 177/559 GB auf 10 GB bzw. darunter ein, was ja dann eigentlich nur zeigt das dies nicht allein nur bei der GTX 970 so ist. Was dann allerdings die Frage aufwirft, warum es dann laut Aussagen der User bei der GTX 980 nicht auch zu nachladerucklern kommt, wie bei der GTX 970 ?

Ihr habt leider noch nicht ganz verstanden, warum sich einige Nutzer ärgern oder warum es diese offene Frage gibt.

Wenn ihr eine 970 oder 980 nutzt und völlig stumpf Nais Benchmark ausführt, brechen beide Karten bei ca. 3,5 GB bei der Bandbreite ein. Wenn jetzt allerdings von der Onboard-GPU (iGPU) gebootet und der WDM deaktiviert wird und der Bench dann auf der jeweiligen GPU ausgeführt wird, bricht die 970 weiterhin ein, währenddessen die 980 über den gesamten Bereich performt.

Einige Nutzer assoziieren das Stuttering genau mit diesem Umstand! Ich gehe mit der vagen Behauptung ins Rennen, dass die Schlussfolgerung falsch ist. Siehe meine letzte Auflistung c).

 

[Masel-for-fun]

VRAM bei GTX 970: Nvidia klärt über 3,5-GiB-Problem auf (Update) auf PCGH