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...