(Angebliches) Problem Mit GTX 970 Und 4GB Grafikspeicher Allozierung

Status
Für weitere Antworten geschlossen.
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Stimmt, aber es steht:
"Note: The below specifications represent this GPU as incorporated into NVIDIA's reference graphics card design. Graphics card specifications may vary by Add-in-card manufacturer."

-> es gibt kein Referenz Design der 970er :fresse:
-> also sind die Boardpartner die "Dummen"...
 
Kannst du mir sagen, was er mit "lahmen Teil einblenden und ausblenden" meint?

Glaube er meint nur, dass die letzten (langsamen) 256MB des VRAMs abgeschnitten werden. Bei insgesamt 2048MB VRAM und 1 SMX-Cluster weniger, sollte der Einbruch eben ab 1792MB beginnen...diese werden dann hier nicht mehr angezeigt.

PS: die GK104 GPU hat 256Bit SI ;)
Auffallend ist allerdings, dass die Bandbreite allgemein auch niedrig ist... Ich hab Werte der 770 gesehen, die auf ~200GB/sec kommt. Wobei dort aber auch 3500er Speicher drauf sind anstatt nur 3000er...

Eine vollwertige GK104 sollte ein 256bit SI haben, auch eine beschnittene GTX670 hat physisch ein 256bit SI. Nur durch der Wegfall von 1 SMX-Cluster hast du dann effektiv ein 224bit SI. Genau das gleiche Spielchen wie bei GTX980 und GTX970...

@Cippoli bitte entferne doch die Thumbnails aus deinem Quote, vielen Dank.

Erledigt.
 
Finde ich auch scheiße was hier gemacht wurde.
Ich sage immer wieder egal AMD/NV die wollen nur unser Geld. Mal schauen wer dieses Jahr besseren Produkt bringt. Werde meine GTX970 beide dann verkaufen und mir NEXT Gen Kaufen.
 
Stimmt, aber es steht:
"Note: The below specifications represent this GPU as incorporated into NVIDIA's reference graphics card design. Graphics card specifications may vary by Add-in-card manufacturer."

-> es gibt kein Referenz Design der 970er :fresse:
-> also sind die Boardpartner die "Dummen"...

Falsch. Die technischen Angaben beziehen sich auf den Chip und dessen Architektur, und der stammt ausschließlich von nVidia.


Der Dumme ist in jedem Fall der Kunde.
 
Natürlich wollen die nur unser Geld, was auch sonst :d
Können sie gerne haben, aber dann bitte ohne Mogellei, ich hätte schon gerne vollwertig Nutzbare 4GB gehabt für mein SLI :(
 
Glaube er meint nur, dass die letzten (langsamen) 256MB des VRAMs abgeschnitten werden. Bei insgesamt 2048MB VRAM und 1 SMX-Cluster weniger, sollte der Einbruch eben ab 1792MB beginnen...diese werden dann hier nicht mehr angezeigt.

Dann müsste er mal ohne DWM testen und/oder noch besser mit der 670er als 2. GPU... Bei Belegung von 0MB auf der GPU sollte der Speicher ja fast voll ausfahrbar sein. Wären die letzten 256MB langsam, müsste der Wert von 1792 bis 1920 weniger Bandbreite aufweisen als der Rest.
Irgendwie scheinen mir die drei Screens aber insich nicht konsistent. Warum sollte der 3. Screen ~10GB/sec mehr Bandbreite aufweisen, ohne hinten einzubrechen? Während 1 und 2 eben weniger Bandbreite aufzeigen über den gleichen Bereich?

Deswegen war ja die Frage, was er da mit ausblenden und beschleunigen meint...
Ggf. antatt Nais Version die aus dem guru3d Forum nutzen. Da kann man die Blöcke ja auf 64MB reduzieren... Wäre interessant was dann raus kommt.

Eine vollwertige GK104 sollte ein 256bit SI haben, auch eine beschnittene GTX670 hat physisch ein 256bit SI. Nur durch der Wegfall von 1 SMX-Cluster hast du dann effektiv ein 224bit SI. Genau das gleiche Spielchen wie bei GTX980 und GTX970...

Ja schonklar, nur sind die Werte allgemein auch ziemlich niedrig... Im Vergleich zu den ~200GB/sec einer 770er und meinen 300GB/sec der 780TI. Ich komme immernoch auf ~10% unter der Theorie. Die 770er mit 1/3 weniger SI und 200GB/sec ist ebenso ~10% unter der Theorie.
Seine Werte zeigen ~20% unter der Theorie -> unabhängig davon, ob da jetzt was durch weniger SMX rauskommt oder nicht.
 
Also die 980 ist nicht betroffen,weil sie vollausbau ist ?
Hab jetzt hier grob durchgelesen. Bin Grad @handy unterwegs.
 
Falsch. Die technischen Angaben beziehen sich auf den Chip und dessen Architektur, und der stammt ausschließlich von nVidia.

Die beiden Sätze hast du aber schon gelesen? Berichtige mich, wenn ich falsch liege, aber "specifications may vary by Add-in-card manufacturer" in Verbindung mit einem fehlenden, weil nicht vorhandenem Referenzdesign ist ein Freischuss für NV. Es gibt kein Referenzdesign, ergo gibts auch keine Karte, die sich an die Werte von NV hält. Alle Designs sind Custom Designs. Mal mit eigenem PCB, mal mit schon gesehenen PCBs älterer Modelle mit leichten Modifikationen. Da steht, dass die Angaben varieren können... Und offenbar tun sie das auch. Da wir kein Referenzdesign haben, können wir auch schlecht nachweisen, dass dies auf diesem anders ausschauen würde.

Das es nicht so sein sollte, brauchen wir nicht zu diskutieren. Mir gehts rein um den Textfakt, der so steht wie er steht...

Also die 980 ist nicht betroffen,weil sie vollausbau ist ?
Hab jetzt hier grob durchgelesen. Bin Grad @handy unterwegs.

So wie es ausschaut ja, die 980er scheint nicht betroffen zu sein, weil eben alle Einheiten werkeln, wie sie sollen...
 
Auffällig ist hier auch die Bandbreite. GTX680 und GTX670 sollten beide 192Gbit/s Speicherbandbreite haben. Die GTX670 hat aber 1 SMX-Cluster weniger, insgesamt 7, darauf folgt 192:8=24...24x7=168Gbit/s. Schon auffällig das der Benchmark genau diese Bandbreite anzeigt...
Mein Fehler - die Benches entstanden mit memoc@1552MHz=>198,7GB/s in GPUz

Wenn mem@1502MHz=>192GB/s in GPUz: 192.jpg


Kannst du mir sagen, was er mit "lahmen Teil einblenden und ausblenden" meint?
Wenn die Karte im Ruhemodus ist wird chunk 14 nicht gefunden, bei leichter Last wird chunk 14 gefunden, erreicht jedoch nur die geringe Bandbreite und im "Gamemodus" wird chunk 14 gefunden und erreicht die gleiche Bandbreite wie die anderen chunks => sieht für mich so aus als würde der Treiber lastabhängig den Speicher freigeben(ein-/ausblenden)
 
Gedankengang eines Noobs, der nicht tief in der Materie drin ist:

Windows belegt doch afaik umd die 200-300MB VRam, wäre es nicht möglich diese fest an die "langsamem" 500MB zu binden? So läge der Verlust im Endeffekt bei nur 200MB da das von Windows ja sowie immer im VRam liegt?!
 
Aber sicher habe ich die Sätze gelesen. Nur machen die deine Aussage nicht besser.

[ironie]Jetzt verstehe ich auch, warum jeder Boardpartner seinen eigenen WHQL-Treiber veröffentlicht, der den VRAM-Gebrauch auf 3,5 GB halten soll. Oder sehe ich das etwa falsch und es gibt nur einen einzigen Treiber, nämlich den von nVidia?[/ironie]
 
Wenn die Karte im Ruhemodus ist wird chunk 14 nicht gefunden, bei leichter Last wird chunk 14 gefunden, erreicht jedoch nur die geringe Bandbreite und im "Gamemodus" wird chunk 14 gefunden und erreicht die gleiche Bandbreite wie die anderen chunks => sieht für mich so aus als würde der Treiber lastabhängig den Speicher freigeben(ein-/ausblenden)

Mhh OK, sowas ähnliches hab ich bei mir auf der TI auch... Was hilft, entweder via Batch den Bench in einer Schleife ausführen lassen, die Karte in den 3D Mode zwingen oder händisch den Bench mehrfach hintereinander ausführen... Bei mir sind die ersten Chunks nämlich mit ~260-270GB/sec langsamer als die hinteren. Was wohl daran liegt, dass die Karte erstmal aus dem idle State raus kommen muss!

PS: kannst du dir mal die extended Version von dem Bench ziehen:
Does the GeForce GTX 970 have a memory allocation bug ? (updated + NV answer)
Und als Chunk 64 angeben -> Menge kann ja bei 2048 bleiben -> er lässt hintenraus sowieso scheinbar den letzten Bereich weg.

Dein letzter Screen zeigt aber eigentlich, dass der Bereich von 1792 - 1920 nicht langsamer ist. Wäre die 670 vom gleichen Problem betroffen, müsste dieser Bereich langsamer sein... Was er offenbar allerdings nicht ist. Sieht für mich so aus, als hat Kepler das Problem nicht!

Windows belegt doch afaik umd die 200-300MB VRam, wäre es nicht möglich diese fest an die "langsamem" 500MB zu binden? So läge der Verlust im Endeffekt bei nur 200MB da das von Windows ja sowie immer im VRam liegt?!

Bin mir nicht ganz sicher, ob man da direkten Einfluss drauf hat, wo die Daten liegen...
Zumal ja nicht ganz raus ist, WO genau die langsamen ~500MB sind. Das ist ja das Problem... Denn nach der Theorie, dass es mit den abgeschalteten SMMs zusammen hängt, kann ja potentiell jeder SMM davon betroffen sein. Und je nachdem, wo man anfängt mit der Adressierung, ist der Bereich mal vorn, mal hinten, mal irgendwo in der Mitte usw.
Wenn der Treiber/das Bios der Karte dann am Ende nur "virtuelle" Adressen rausgibt, bekommt der User nichtmal mit, wo der Bereich genau abgelegt ist -> also welche physische VRAM Zelle bzw. über welchen physischen Controller.

Das kannst du dir ähnlich einer SSD vorstellen. Da gibts auch die übliche Zählweise via LBA. Physisch sind die Daten aber wohl ganz anders addressiert. Man benötigt diese Zählweise analog der HDDs aber auch zu kompatibilitätszwecken. Wenn du allerdings bei einer SSD in vorderen LBA Bereich Daten schreibst, heist das lange nicht, dass die Daten auch wirklich "vorn" geschrieben werden. Und wenn du hinten die letzten LBAs mit Daten füllst, heist das nicht, dass es auch die letzten Zellen der SSD benutzt. Schon alleine Trim verbietet dir das -> weil die Zellen möglichst gleich beschrieben werden sollen. Heist, die Adressierung ist eigentlich nur virtuell und die Zuordnung von virtueller Adresse zu physischer Zelle übernimmt eine Ebene tiefer...

Um diese "Priorisierung", wie NV es wohl schimpft, bewerkstelligen zu können, müsste das ähnlich laufen... Virtueller Adressraum und irgendwo in der Karte übernimmt eine Logik das Übersetzen von virtueller Adresse auf physische Zelle. Ob man da selbst Einfluss drauf hat? Bzw. das OS? Ich denke nicht...
 
Fdsonne, Anandtech betrachtet eigentlich immer vorher das Blockschaltbild.
Aus dem müsste doch hervorgehen, was mit wem und wie verbunden ist.

Das meinte ich. Bei den meisten Reviews kannst du doch schon einfach sehen, dass da nur die Specs von Nvidia Folien abgeschrieben wurden.
 
Um diese "Priorisierung", wie NV es wohl schimpft, bewerkstelligen zu können, müsste das ähnlich laufen... Virtueller Adressraum und irgendwo in der Karte übernimmt eine Logik das Übersetzen von virtueller Adresse auf physische Zelle. Ob man da selbst Einfluss drauf hat? Bzw. das OS? Ich denke nicht...

Ah ok, war wie gesagt nur eine einfache Idee :)
Hätte ja sein können, das Nvidia da Treiberseitig was macht/machen kann, um den Leistungsverlust nur auf die letzten 250~MB zu beschränken in 3D Anwendungen
 
Irgendwie scheinen mir die drei Screens aber insich nicht konsistent. Warum sollte der 3. Screen ~10GB/sec mehr Bandbreite aufweisen, ohne hinten einzubrechen? Während 1 und 2 eben weniger Bandbreite aufzeigen über den gleichen Bereich?

Ja schonklar, nur sind die Werte allgemein auch ziemlich niedrig... Im Vergleich zu den ~200GB/sec einer 770er und meinen 300GB/sec der 780TI. Ich komme immernoch auf ~10% unter der Theorie. Die 770er mit 1/3 weniger SI und 200GB/sec ist ebenso ~10% unter der Theorie.
Seine Werte zeigen ~20% unter der Theorie -> unabhängig davon, ob da jetzt was durch weniger SMX rauskommt oder nicht.
Mein Fehler - die Benches entstanden mit memoc@1552MHz=>198,7GB/s in GPUz

Wenn mem@1502MHz=>192GB/s in GPUz:

Jetzt wissen warum der 3. Screen etwa 10GB/s mehr anzeigt. Aber dennoch sollten da 192GB/s bzw. zumindest 168GB/s stehen und nicht 153GB/s. Mindestens die fehlenden 15GB/s von 168GB/s zu 153GB/s müssten, wie fdsonne bereits festgestellt hat, irgendwie noch erklärt werden.
 
Aber sicher habe ich die Sätze gelesen. Nur machen die deine Aussage nicht besser.

[ironie]Jetzt verstehe ich auch, warum jeder Boardpartner seinen eigenen WHQL-Treiber veröffentlicht, der den VRAM-Gebrauch auf 3,5 GB halten soll. Oder sehe ich das etwa falsch und es gibt nur einen einzigen Treiber, nämlich den von nVidia?[/ironie]

Worauf willst du mit dem Treiber hinaus? Der Treiber hat doch mal gar nix mit den Spezifikationen der Hardware zu tun. Und wenn da steht, das die Spezifikationen bei einem Custom Design eines Boardpartners abweichen können vom Refernezdesign -> was es nicht gibt!!, dann heist das im Endeffekt, dass NV nur diesem nicht vorhandenen Referenzdesign zusichert, da auch die Daten zu bieten, die sie da schreiben.
Jede 970er ist Custom, also fällt jede 970er unter "may vary". Übersetze diese beiden Wörter und stelle fest, dass "may vary" alles andere heist, als es MÜSSE so sein wie dort steht. Es heist viel eher, es kann mehr, es kann weniger oder auch es kann gleich sein. Frag doch bitte beim Boardpartner -> sinngemäß.

Fdsonne, Anandtech betrachtet eigentlich immer vorher das Blockschaltbild.
Aus dem müsste doch hervorgehen, was mit wem und wie verbunden ist.

Dieses Blockschaltbild sagt aber nix über die Kommunikation selbst aus... Nichts über mögliche Flaschenhälse und vor allem auch nichts über die Zusammenhänge der einzelnen Teile. Es stellt viel eher einen Überblick über das ganze dar.
Mal im Vergleich, damals zu R600 Zeiten hat AMD ebenso ein Bild veröffentlicht. Daraus ging hervor, dass die HD2900XT 64xVLIW5 Einheiten verbaut hatte. 64x5 wären/sind 320 "ALUs", wenn man so will. Das Blockbild sagt aber nix über die Arbeitsweise und die Zusammenhänge. Klar die Einheiten sind so vorhanden und auch so nutzbar. Um den Vorteil dieser Einheiten allerdings auszufahren sind gewisse Bedingungen notwendig. Und so kam es eben, dass die HD2900XT, trotz bedeutend mehr "ALUs" nach zusammenrechnen der Einheiten nicht an den 128 "1D" Einheiten von NVs G80 vorbei kam. Deswegen hat das Blockschaltbild aber nicht gelogen... Das mein ich damit.

Ob und was NV hier konkret an Infos zum GM204 publiziert, ist für mich nicht ersichtlich. Müsste man mal eine Redaktion/einen Reviewer konkret befragen... Im Endeffekt aber auch völlig nebensächlich, da man ja nix an der Situation ändert mit der Aussage ;)

Ah ok, war wie gesagt nur eine einfache Idee :)
Hätte ja sein können, das Nvidia da Treiberseitig was macht/machen kann, um den Leistungsverlust nur auf die letzten 250~MB zu beschränken in 3D Anwendungen

Eventuell kann NV da was drehen... Reingucken kann ja bestenfalls NV, also wenn, dann kann der Hersteller da was hinbiegen oder verbessern. 100% ausgeschlossen ist das definitiv nicht. Ob es allerdings so kommt? Keine Ahnung...
 
Jetzt wissen warum der 3. Screen etwa 10GB/s mehr anzeigt. Aber dennoch sollten da 192GB/s bzw. zumindest 168GB/s stehen und nicht 153GB/s. Mindestens die fehlenden 15GB/s von 168GB/s zu 153GB/s müssten, wie fdsonne bereits festgestellt hat, irgendwie noch erklärt werden.

Möglicherweise doch ein ähnliches Verhalten der 970er. Nur eben, dass obenrum die Karte nicht einbricht, weil keine 1:1 Mappung des Speichers auf die SMX besteht. Sondern "nur" durch weniger SMX weniger gesamt Bandbreite in Richtung Crossbar existiert. Ganz abwägig ist das ja nicht... Denn die Bandbreite kommt ja nicht aus der Luft.
Überlegt man mal etwas genauer, dann misst der Benchmark nicht die eigentliche Speicherbandbreite, sondern viel eher den Durchsatz vom Shadercluster zum VRAM Chip. -> jeglicher Flaschenhals dazwischen vermindert den realen Durchsatz.

Was gerade bei GK104 sehr interessant bei dem Thema ist. Die OC Skalierung der 680er obenrum ist ja sehr mau. Bei einigen Titeln gerade mal 2:1, wenn man die VRAMs nicht mit hoch schraubt. Der 670er scheint bei weniger gesamt Bandbreite allerdings dies keinen Abbruch zu tun, wenn ich mir die damaligen Bandbreiten-Skalierungstests in Erinnerung hole. Der absolute Leistungsunterscheid bei GPU Taktgleichheit ist zwischen der 670er und 680er sehr gering. -> ~5% und damit weniger als der theoretische Nachteil durch die Teildeaktivierung. Damals ging man noch davon aus, das pro Rohleistungseinheit die 670er mehr Bandbreite hat und deswegen etwas besser obenraus skaliert. Nach den Werten hier dürfte das ja allerdings nicht der Fall sein. :confused:
 
...er lässt hintenraus sowieso scheinbar den letzten Bereich weg

Das ist auch so beabsichtigt, da sich teilweise noch Daten im VRAM befinden. Man sieht deshalb bei vielen auch eine Inkonsistenz beim Beginn des Einbruchs. Aus dem Grund beginnt es bei einigen schon unter 3GB einzubrechen, bei anderen später, da muss man dann schauen wieviel VRAM bereits belegt sind, bevor man den Benchmark startet.

- - - Updated - - -

Möglicherweise doch ein ähnliches Verhalten der 970er. Nur eben, dass obenrum die Karte nicht einbricht, weil keine 1:1 Mappung des Speichers auf die SMX besteht. Sondern "nur" durch weniger SMX weniger gesamt Bandbreite in Richtung Crossbar existiert. Ganz abwägig ist das ja nicht... Denn die Bandbreite kommt ja nicht aus der Luft.
Überlegt man mal etwas genauer, dann misst der Benchmark nicht die eigentliche Speicherbandbreite, sondern viel eher den Durchsatz vom Shadercluster zum VRAM Chip. -> jeglicher Flaschenhals dazwischen vermindert den realen Durchsatz.

Der Gedankengang gefällt mir.

Was gerade bei GK104 sehr interessant bei dem Thema ist. Die OC Skalierung der 680er obenrum ist ja sehr mau. Bei einigen Titeln gerade mal 2:1, wenn man die VRAMs nicht mit hoch schraubt. Der 670er scheint bei weniger gesamt Bandbreite allerdings dies keinen Abbruch zu tun, wenn ich mir die damaligen Bandbreiten-Skalierungstests in Erinnerung hole. Der absolute Leistungsunterscheid bei GPU Taktgleichheit ist zwischen der 670er und 680er sehr gering. -> ~5% und damit weniger als der theoretische Nachteil durch die Teildeaktivierung. Damals ging man noch davon aus, das pro Rohleistungseinheit die 670er mehr Bandbreite hat und deswegen etwas besser obenraus skaliert. Nach den Werten hier dürfte das ja allerdings nicht der Fall sein. :confused:

Seltsam, wir müssten mal eine GTX680 durch den Benchmark laufen lassen, nur um sicher zu gehen, dass diese auch die volle Bandbreite von 192GB/s erreicht.
 
*Edit:

Wurde schon in einem Link eine Seite zuvor gepostet.
 
Zuletzt bearbeitet:
mmhhh nach zig Jahren von AMD auf Nvidia gewechselt und nun sowas... na danke

jetzt könnte ich natürlich meine 970 GTX zurückschicken... mmmhhh
 
Bin auch etwas verärgert, egal ob das Problem jetzt realitätsnah ist oder nicht....nur es gibt ja keine alternative für ein 970er SLI. Zwei 290(X) häng ich mir sicher nicht ins Gehäuse, 980 ist P/L technisch Grütze :(
Mal schaun was die 380X im Mai/Juni sagt
 
Zuletzt bearbeitet:
Bin auch etwas verärgert, egal ob das Problem jetzt realitätsnah ist oder nicht....nur es gibt ja keine alternative für ein 970er SLI. Zwei 290(X) häng ich mir sicher nicht ins Gehäuse, 980 ist P/L technisch Grütze :(
Mal schaun was die 380X im Mai/Juni sagt

jo bin gespannt aber bis dahin dauerts leider zu lange

habe derzeit keine Grafikkarte außer der 970 GTX und könnte sie innerhalb der Rückgabefrist zurückschicken.... aber was soll ich ohne Grafikkarte schon machen.
 
welche Alternativen gibt es, die änliche Ansprüche erfüllen wie ne 970?
ne 780 oder 780Ti.
 
Ich glaube meine nächsten Karten werden wieder AMD sein. Was NV hier Leistet ist schon ****** oder die Board Partner. Spulen fiepen und dann das, es wird immer Lächerlicher.
Wenn das AMD machen würde aber Hallo.

Dann muss ich immer Lesen NV Exzellente Hardware und Co aus dem Grund Zahle ich mehr. Ja Ja NV Exzellente Hardware fürn Arsch.
Sowas darf man als Kunde nicht Akzeptieren und nicht unterstützen.

Ich bin zwar nicht betroffen mit diesen Fehler aber was ich Lese und Höre finde ich absolute Frechheit was NV sich hier Leistet.
 
ob der Preis deswegen für NV Verhältnisse so niedrig angesetzt wurde?
Hauptsache schnell weg mit den Karten.
 
welche Alternativen gibt es, die änliche Ansprüche erfüllen wie ne 970?
ne 780 oder 780Ti.

Dann kann er gleich bei seinen knapp 3,5 Gb bleiben.:)
Da 780 mindestens genau so teuer und mehr kosten.
Tendenz ist so oder so mehr wie 4 GB in den nächsten Monaten die 8GB bei den Konsolen wovon zur Zeit bis zu 6GB genutzt werden schlagen so langsam durch auf den PC Markt.
 
Zuletzt bearbeitet:
Status
Für weitere Antworten geschlossen.
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh