Speichermanagement von Nvidia Karten

JackA

Urgestein
Thread Starter
Mitglied seit
08.05.2006
Beiträge
8.876
Ort
Oberbayern
Servus,

ich wollte mal gerne Wissen, ob Nvidia ihr Porblem mit dem Speicher mittlerweile im Griff hat? und am welcher Grafikkarte von Nvidia tritt des Problem nichtmehr auf, falls es denn schon gelöst wurde?
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
ein richtiges Problem gibt es da nicht, nur ein "anderes" Handeln des Speicher kontrollers ( ATI <> NV ) die einen (ATI) löschen den Speicherinhalt sofort wieder, und NV lässt es länger im RAM, was bei wiederkehrenden Frames ein vorteil ist ( die sind noch im RAM ), was aber im falle des einmaligen Frames dann mal ein nachteil werden kann. Anders herum, kann es z.B bei Strategie Games sein, das du zu einer Insel zurück scrollst, und die ist nicht mehr im RAM, dann hast du da deine Ruckler.(ATI)
Bei NV würde ich ein Karte ab 9800GT nurnoch mit 1024MB Kaufen, bei ATI reichen meisst noch 512MB.
Bei NV war das aber nur bei den mit "nur" 256MB ein Problem
 
Zuletzt bearbeitet:
Mir ist das damals aufgefallen, ich hatte eine 8800GTS 640mb und nach ca. 10min diverse vermehrt auftretende Ruckler. Bei WoW lief ich wie durch Gummi anstatt durch Luft. Die ganzen Probleme hab ich mit der ATI nichtmehr. Also gehe ich mal davon aus, dass das an den G80 Chip gelegen hat + Treiber.
 
hab nen kumpel dermit seienr G80 88GTS 640mb auch wow udn andere games ohne ruckler spielt also muss es nciht unbedingt an der Karte liegen oder?
 
natürlich wurden die Treiber angebasst, und die G9x GPUs dahingehend Optimiert, aber ein echter "BUG" war es nie.
und bei Karten mit G9x GPU und mindestens 512MB ist es erträglich, aber da ich eine 9800GT mit 1024MB habe, habe ich es nicht !
 
Wie schon angesprochen wurde, ein echten Bug oder Fehler gab es da nicht...

Einzig die These, das eben Daten über sehr lange Zeit im Speicher gehalten werden (was nach wie vor so ist) brachte damals Karten mit wenig VRam extrem aus dem Tritt und führte zu teils dauerhaft niedrigen FPS.

Es wurde aber mit Sicherheit bei NV auch an der Sache gearbeitet um dieses extremwegbrechen bei VRam Mangel zu unterbinden bzw. abzuschwächen...
So sieht man jetzt auch mit großen Karten wie die 9800GTX+ mit 512MB idR keine so drastischen Einbrüche nach längerer Spielzeit wie damals mit den G80 Modellen ala 320MB GTS.

An der GPU ansich lag das aber eigentlich nicht, denn auch die kleine 256MB 8800GTS mit G92 Chip hatte damals zu kämpfen...
 
Wenn es kein Bug ist, was dann?
Kann ja wohl nicht normal sein das sich der Vram nicht mal löscht, wenn das Ding schon so voll ist das es ruckelt!
War bei meiner 8800GT auch der Fall, erst schnell, dann nach kurzer Zeit am ruckeln und man muss selbst den Vram löschen. Wenn das so richtig sein soll, dann weiß ich auch nicht.....
Bei den alten G80 mit 640MB war das nicht so krass...naja war auch nicht so kastriert wie die neuen mit 256 Bit SI.
 
Zuletzt bearbeitet von einem Moderator:
Das Problem wohl eher folgendes:
Woher soll die Software wissen, welche Daten potentiell raus können und welche noch drin bleiben sollten? Sprich die Routine, welche die Daten rauslöscht war damals weit unoptimierter als sie es heute ist.
Denn offensichtlich wurden damals wahlweise bei Speicherknappheit Files rausgeschmissen, ohne Rücksicht auf Verluste, was bei häufig verwendeten Daten eben zu massiven Nachladerucklern führte... Bzw. es wurden einfach die Daten, die nicht mehr mit in den VRam passten in den Ausgelagerten Bereich im RAM geladen, obwohl diese gerade benötigt wurden und somit direkt aus dem Arbeitsspeicher kommen und nicht aus dem VRam.

Scheinbar ist die Sache aber mittlerweile soweit optimiert wurden, das die Software mehr oder weniger gut vorhersagen kann, welche Daten potentiell noch gebraucht werden und drin bleiben und welche Daten raus können...
Man hat auch damals ne 800GTX/Ultra zu dem Problem zwingen können, es bedurfte nur der nötigen Software, welche den VRam derart füllen konnte...
Kann ja mal jemand nachtesten, GTA IV mit ner 8800GTX/Ultra oder GTS 640MB aber mit nem Treiber von Anfang-Mitte 2007... Sollte früher oder später in ner Ruckelorgie enden...

Wie und was genau da abläuft, kann aber nur NV selbst beantworten, was sie nicht tun werden...

EDIT:
@Tectrex
ich bitte um Entschuldigung und hoffe du kannst mir das verzeihen, bin neu als Mod und hab ausversehen deinen Beitrag editiert, obwohl das nicht gewollt war...
Sorry nochmal. Wird nicht wieder vorkommen
 
Naja wenn man weiß das der Vram nicht regelmäßig gelöscht wird, sollte man das SI nicht weiter kastrieren. Man sieht ja das es bei den alten G80 besser ging (außer bei der 320er).
Aber mit den Nachtesten wäre ne gute Idee.

@Tectrex
ich bitte um Entschuldigung und hoffe du kannst mir das verzeihen, bin neu als Mod und hab ausversehen deinen Beitrag editiert, obwohl das nicht gewollt war...
Sorry nochmal. Wird nicht wieder vorkommen
NP :)
Das ist mir als Mod auch schon passiert in meiner Anfangszeit, leider nicht nur einmal^^:fresse:
Da will man Antworten hat aber auf den falschen (neu dazugekommenen) Button geklickt und denkt man antwortet :d
Gratuliere zum Mod :)
Gute Wahl haben sie da getroffen.
 
Zuletzt bearbeitet:
hmm also es ist aber auch speile abhängig. zumbeispiel meinem kleinen bruder sein kumpel(eher für die eltern), dem ich nen Pc für 250€ zusammgestellt habe mit ner 88GT 256mb(die gabs neu für 25€), daruckeln seine games nciht. Er spielt needforspeed mostwanted und legostarwars usw auf 17Zoll.

mal ne nebenfrage, wie wird man den mod?
 
Naja, nen Nachtest mit alten Treiber könnte aber zu neuen Problemen führen die nicht den VRam betreffen und die Ergebnisse verfälschen.

Mal so als Frage nebenbei, da die Texturen bei normalen Spielen ohne Kompression ja "Fertig" vorhanden sind ohne berechnet werden zu müssen, sollte man doch eigentlich eh bald die gesammten Texturen im VRam unterbringen können (sagen wir mal ab 2 Gib).

Ansonsten kann man den PCIe Bus auch übertakten um somit die Auslagerung zu beschleunigen.

@fdsonne
Glückwunsch zum Modstatus;)
 
@Neurosphere: Naja, ganz so einfach geht das nicht, soweit ich weiß. Während des Renderings kann möglicherweise noch eine große Datenmenge an prozeduralen Texturen (im Sinne von Ergebnisse von Render-to-Texture-Passes) erzeugt werden, die du so vorher nicht abschätzen kannst. Einfach alles im VRAM unterzubringen wäre also ein bisschen blauäugig, weil es immernoch passieren kann, dass dir die Geschichte irgendwann überquillt. Außerdem gibts ja durchaus vernünftige Kompressionsverfahren in Hardware.
Was die Übertaktung des PCIe-Buses angeht, na, so weit geht der ja meist nicht :) Wenn man da 20% Mehrleistung rausholt, kann man sich schon glücklich schätzen. Außerdem wird die Geschwindigkeit der Auslagerung ja nicht nur vom PCIe-Interface bestimmt. Mich würde mal interessieren, ob man hier mit einem asynchronen Bussystem Vorteile erzielen könnte.

@HD4870: Du bewirbst dich, wenn mal wieder eine Anfrage da ist, und hast dann entsprechend Glück ;) so wie fdsonne und meine Wenigkeit hier zum Beispiel.
 
Naja wenn man weiß das der Vram nicht regelmäßig gelöscht wird, sollte man das SI nicht weiter kastrieren. Man sieht ja das es bei den alten G80 besser ging (außer bei der 320er).
Aber mit den Nachtesten wäre ne gute Idee.
Das SI ansich sollte da eher das geringste Problem darstellen, vor allem wenn man bedenkt, die Daten werden ja im Arbeitsspeicher ausgelagert. Solange dieser genügend Bandbreite zur Verfügung stellt, ist der Flaschenhals in der Kette immernoch der PCIe Port. Ob der VRam beispielsweise nun 50GB/sec oder 100GB/sec übertragen könnte sollte da das geringste Übel spielen, wenn sowieso nur maximal theoretisch 8GB/sec bei 16x und PCIe 2.0 durch den Slot passen...
Gab da ja mal Tests bei THG über die PCIe Port Anbindung... Zeigte recht gut, wie stark die 320MB GTS damals eingebrochen ist, wenn ihr der VRam ausging und die PCIe Anbindung reduziert wurde.
Leider wurde im Vergleich keine GTX oder 640MB GTS getestet, da wäre das Ergebniss mit Sicherheit weit anders ausgefallen ;)

NP :)
Das ist mir als Mod auch schon passiert in meiner Anfangszeit, leider nicht nur einmal^^:fresse:
Da will man Antworten hat aber auf den falschen (neu dazugekommenen) Button geklickt und denkt man antwortet :d
Gratuliere zum Mod :)
Gute Wahl haben sie da getroffen.

Das beruhigt mich, das ich nicht der erste bin, dem sowas passiert...
Und stimmt, genau daran lags, der Edit Button ist neu und die Gewohnheit tut ihr übriges dazu... :fresse:

hmm also es ist aber auch speile abhängig. zumbeispiel meinem kleinen bruder sein kumpel(eher für die eltern), dem ich nen Pc für 250€ zusammgestellt habe mit ner 88GT 256mb(die gabs neu für 25€), daruckeln seine games nciht. Er spielt needforspeed mostwanted und legostarwars usw auf 17Zoll.

mal ne nebenfrage, wie wird man den mod?

Das ist logischerweise klar, von der Anwendung hängt ab, wie viel VRam belegt wird, und von den eingestellten Details, die Auflösung spielt mittlerweile nur noch ne untergeordnete Rolle...
Die von dir genannten Games sind ja mehr oder weniger älteren Semesters bzw. wenig anspruchsvoll.

Mod wird man, indem man sich für den Posten bewirbt, gab da ja vor einiger Zeit ne Ausschreibung oder wenn man von der Forenleitung angesprochen und gefragt wird.

Naja, nen Nachtest mit alten Treiber könnte aber zu neuen Problemen führen die nicht den VRam betreffen und die Ergebnisse verfälschen.

Mal so als Frage nebenbei, da die Texturen bei normalen Spielen ohne Kompression ja "Fertig" vorhanden sind ohne berechnet werden zu müssen, sollte man doch eigentlich eh bald die gesammten Texturen im VRam unterbringen können (sagen wir mal ab 2 Gib).

Ansonsten kann man den PCIe Bus auch übertakten um somit die Auslagerung zu beschleunigen.

@fdsonne
Glückwunsch zum Modstatus;)

Das stimmt, es könnte zu Problemen kommen, aber ohne das es jemand testet, werden wir es nicht wissen ;)

Aber ich glaube mal nicht, das 2GB Speicher reichen werden um die gesamten Texturen auf die Karte zu bringen.
 
Außerdem gibts ja durchaus vernünftige Kompressionsverfahren in Hardware

Mir fällt da direkt S3TC ein. Allerdings scheint das ganze nicht mehr so aktuell zu sein. Zwar wurde es in DX integriert und auch in Open GL, aber mir fällt jetzt kein neueres Spiel ein welches explizit darauf setzt. Es gab wohl auch einige Probleme mit der Kopression.

Was die Übertaktung des PCIe-Buses angeht, na, so weit geht der ja meist nicht Wenn man da 20% Mehrleistung rausholt, kann man sich schon glücklich schätzen.

Stimmt, viel mehr ist wohl nicht drin. PCGH printed hat allerdings mit 20 MHz mehr teilweise bis zu 34% mehr Leitung erzielen können, gerade bei GTA4. Es soll ja auch keine Lösung sein, sondern nur eine Option für User die Probleme mit dem VRam haben.

Edith sagt:

Aber ich glaube mal nicht, das 2GB Speicher reichen werden um die gesamten Texturen auf die Karte zu bringen.

Stimmt. Allerdings scheint der VRam in nächster Zeit überproportional zu wachsen. Gerade jetzt wo die Hersteller mehr Freiraum von NV bekommen haben. Die Frage ist halt nur wie sich die größe der Texturen in Spielen in nächster Zeit entwickeln wird.
 
Zuletzt bearbeitet:
Stimmt, viel mehr ist wohl nicht drin. PCGH printed hat allerdings mit 20 MHz mehr teilweise bis zu 34% mehr Leitung erzielen können, gerade bei GTA4. Es soll ja auch keine Lösung sein, sondern nur eine Option für User die Probleme mit dem VRam haben.

Man brauch sich ja der Einfachheit halber nur mal PCIe 1.x vs. PCIe 2.0 Tests angucken...
IdR steigt die FPS Rate nicht wirklich spürbar bei Verdopplung der Bandbreite.

Einzige derzeit mir bekannte Ausnahme, CoD4 profitiert sehr stark von mehr PCIe Slot Performance...
 
Aber ich glaube mal nicht, das 2GB Speicher reichen werden um die gesamten Texturen auf die Karte zu bringen.

Man denke zum Beispiel mal an idTech5 und die Megatexture-Technologie. Unkomprimiert sind das hunderte Gigabyte an Daten. Die Grafikkarte möchte ich sehen. :)

Und was das angeht, Arbeitsspeicher wird - sogar bei einer extrem schnellen, nahezu unendlich schnellen - Busverbindung immer noch bedeutend schlechter sein, als es der VRAM ist, weil die physische Entfernung zur GPU einfach zu groß ist. Da gehen viel zu viele Taktzyklen einfach an Latenz verloren. Davon lässt sich vielleicht etwas durch geschicktes Pipelining und - wie ich sagte - einen asynchronen Bus zurückgewinnen, aber erstens ist das Augenwischerei (wer glaubt schon, dass das PCIe-Bussystem komplett über den Haufen geworfen wird?) und zweitens bleibt der RAM immernoch langsamer. :)
 
Man denke zum Beispiel mal an idTech5 und die Megatexture-Technologie.

Ja, da hab ich auch schon von gelesen. Allerdings ist die Frage in wie weit id die Technik einsetzen wird. Wenn ich mich nicht täusche liegen die Texturen komprimiert im Ram und werden vor der Ausgabe hochgerechnet. Somit bräuchte ich die riesigen Texturen die dabei entstehen doch eh nicht mehr in den VRam auslagern.

Es gab da mal eine Technik die Texturen um das x-fache komprimieren konnte, leider finde ich da keine Informationen mehr zu. Es gab allerdings ein Spiel für die PS3 (downloadbar) das von einer Gesamtgröße von 600 MB auf 80 MB geschrumpft ist. Die Texturen lagen dabei allerdings wohl Komplett im VRam, wurden aber vor der Szenerie berechnet und dann ausgelagert. KKrieger ist so ein Beispiel, das wurde auch mit dieser Technik porgrammiert.
 

Anhänge

  • kkrieger-beta.zip
    97,8 KB · Aufrufe: 28
ID setzt die Technik ja bereits ein, QuakeWars läuft absolut auf Megatexture. :) Du hast aber Recht, das Verfahren ist ein wenig anders. Die Texturen sind vorkomprimiert und die GPU bekommt nur diese Texturen und einen Algorithmus, wie und wann sie die wieder zu entpacken hat. Trotzdem bleibt der Fakt bestehen, dass man die gesamte Informationsmenge, die dort in Form von Texturen verwendet wird, nie unkomprimiert in einen VRAM bekommen würde. Das meinte ich.

Diese andere Technik, von der du sprichst, nennt sich "Procedural Textures". Deswegen war ich da oben auch mit dem Begriff der prozeduralen Texturen vorsichtig, weil ich eben nicht das meinte, sondern Render-to-Texture. Das Problem an Procedural Textures hier ist einfach, dass sie mathematisch ziemlich anspruchsvoll sind. Nicht jeder dahergelaufene Programmierer wird damit vernünftig arbeiten können, das war zumindest die Befürchtung der Entwickler. Ansonsten muss ich aber auch zugeben, dass mich dieser Ansatz ziemlich begeistert und ich hoffe, dass sich der ein oder andere Entwickler mal damit befasst.
 
@Lord
das stimmt natürlich, der Arbeitsspeicher bleibt für die direkte Nutzung durch die GPU in heutiger Form zu langsam um nur Ansatzweise fehlenden VRam auszugleichen...

Aber ich finde den Ansatz ansich aber schon mal nicht schlecht mit dem Auslagern in den RAM, weil die Daten erneut von der HDD holen zu müssen wäre imho noch fataler ;)

@Neurosphere
kkrieger ansich ist schon sehr interessant, in dem Fall für die Texturen aber bewirkt es auch keine echten Wunder. Irgendwo müssen die Daten ja hin, und so extrem hochauflösend und gutaussehend sind diese dort ja nicht. Vor allem, wiederholen sich auch extrem oft...
Sowas will in echten Endkundengames wo keiner mehr sehen, da muss wenn möglich jeder Pflasterstein auf der Straße anders aussehen...
 
Jup, das meinte ich, habs gerade auch wieder gefunden.

Hier ist ein interessantes Interview dazu:
http://www.projectlan.de/artikel/Re..._Welten__Procedural_Textures-special-1-32.htm

Das Problem an Procedural Textures hier ist einfach, dass sie mathematisch ziemlich anspruchsvoll sind.

Eben das steht dem größeren Einsatz der Technik im Wege. Die Frage ist aber eigentlich auch, wie stark der Arbeitsaufwand steigt wenn man solche extremen Texturen in die Spiele integriert. Und damit meine ich nicht nur den Aufwand für die Grafikkarte, sondern auch den bei der Entwicklung des Spiels selbst (zum einen mathematisch, zum anderen müssen die Texturen ja auch erst von den Entwicklern "erschaffen" werden).

Gabe Newell hat sich übrigens damals schon dafür ausgesprochen das Grafikkarten endlich mehr als 2Gib VRam haben sollten (war glaub ich vor 3 Jahren).



Edith sagt:

Sowas will in echten Endkundengames wo keiner mehr sehen, da muss wenn möglich jeder Pflasterstein auf der Straße anders aussehen...

Haha, das ist schon richtig. Aber stell dir vor das Spiel hat nur 96KB und wurde um den Faktor 10 kleiner (der Wert ist jetzt rein spekulativ und nur zum veranschaulichen!).
Das Spiel hätte somit im original knapp 1 MB an größe gehabt wenn man die Technik nicht eingesetzt hätte. Wenn das Spiel jetzt aber mehr Texturen einsetzt, was ja ohne Zweifel möglich wäre, würde es vielleicht von 20MB auf 2 MB schrumpfen mit der Technik. Falsch ist daran also nichts und die Demo dient ja nur dazu das mögliche zu zeigen und nicht als Vollpreisspiel;)

Allerdings werden die Procedural Textures doch vor der Ausgabe in den VRam ausgelagert und vorher einfach nur hochgerechnet, jedenfalls ist es so bei kkrieger der Fall.
 
Zuletzt bearbeitet:
Einzige derzeit mir bekannte Ausnahme, CoD4 profitiert sehr stark von mehr PCIe Slot Performance...

jetzt weiß ich auch, warum ich mit meinem system immer ein gutes stück unterhalb der benchmarksysteme bei CoD4 lag... :fresse:
 
jetzt weiß ich auch, warum ich mit meinem system immer ein gutes stück unterhalb der benchmarksysteme bei CoD4 lag...

Bei deiner Karte solltest du aber eben jenes Problem nicht haben, da ATi nen anderes Speichermanagment hat.
 
fdsonne hat ja geschrieben, dass man bei COD4 den unterschied zwischen PCI-e 1.0 und 2.0 merkt ;)
 
fdsonne hat ja geschrieben, dass man bei COD4 den unterschied zwischen PCI-e 1.0 und 2.0 merkt

Ich les auch immer nur die hälfte:fresse:

Aber stimmt, das merkt man schon. Nen Bekannter von mir hat sein Board ausgetauscht und hat somit bei sonst gleicher Hardware von 1.0 auf 2.0 gewechselt. Allein durch den Wechsel hat er im 3DMark06 13k statt 12k Punkte. Andere vergleichswerte hab ich leider nicht, aber immerhin.
 
hab noch ein 965P board und hab mir schon überlegt, ein P45 board zu holen, aber erstens bin ich student (geld) und zweitens wollte ich den E8400 und das board noch solange behalten, bis ich einen Quad (mehr kerne) brauche...weiß nicht, ob das meine 4870 einbremst? :confused:
 
Naja, so gravierend dürften die Performanceunterschiede nicht sein. Allerdings gibt es schon günstige P45 Boards, was wohl auch das OC-Potential deines E8400 erhöht.

Die Sache mit dem armen Studenten kenne ich....
 
ob wohl jedes P45 board FSB500 macht wie mein P965? ;)
 
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