Mod als BSA braucht mehr Speicher?

Es ging mir ja auch weniger darum, ob du die Werte richtig ausgelesen hast, das glaub ich dir einfach mal, sondern bei meiner Anmerkung zu ENBoost ging es eben darum, dass es eben deutlichen Einfluss auf die RAM-Belegung und auch einen leichten Einfluss auf die VRAM-Belegung hat. Darauf bezog sich das "mit ENBoost ist es schwer, klare Schlüsse zu ziehen" in Bezug auf "BSA belastet den VRAM mehr als Lose Files"

 

es ist etwas komplizierter, ja, aber im Ergebnis sieht man dann, dass die gezeigten Angaben im PerformanceMonitor recht gut sind.:
Im Taskmanager Filesize und Speicherbelegung von ENBhost.exe und TESV.exe monitoren, dazu bei Taskmanager/Leistung und Resourcenmonitor Rambelegung. Vergleichen mit Angaben in PerformanceMonitor. Dann Skyrim starten mit VRam-belegenden Mods (BSA / loose Files). Dann sieht man, dass ENBhost.exe "wächst" mit zunehmendem Speicherbedarf. ENBHost.exe hat im inaktiven Zustand nur eine Rambelegung von 440 KB. Ist 32bit.Programm, kann bis 3GB handlen. Genau das macht es, es wächst mit + Vram auf der Graka. Nicht völlig transparent ist, was von dem, um das ENBHost.exe wächst, nun eigentlich Grafik wäre und was eigentlich "nur"Arbeitspeicher wäre, zumal die im Taskmanager angezeigte RAM-Belegung mehr anschwillt, als das Wachstum der ENBHost.exe. (Bespiel aus der Erinnerung früheren Monitorens: Rambelegung knapp 8 GB, knapp 4GB Graka belegt, ENBHost.exe lt. Taskmanager 2.3GB gross.) PerformanceMonitor zeigt den RAM-Gesamtwert und den der Belegung bei der Graka an. In so fern belastet BSA VRam und Ram und CPU mehr, als lose Files, abhängig von dem Inhalt des BSA.
Bzgl. BSA: zu grosses BSA kann CTD beim Laden verursachen, während dasselbe als loose Files problemlos läuft. (Nicht von Ungefähr hat Skyrim mehrere BSA, das grösste ist nur 1.5 GB)

Nachtrag:
hab gerade nochmal oldSkyrim geladen und mit 4 Begleitern meine Testroute Elysium - Brücke - Ebental - Flußwald gelaufen.
TESV.exe hat vor Start Grösse 17.602 KB
ENBHost.exe hat vor Start Grösse 440 KB
Nun Vergleich der angezeigten Belegung in Win7/64 Task Manager and Resourcenmpnitor und PerformanceMonitor:

 

Du missverstehst mich. Ich glaub dir, dass du richtig gerechnet hast und auch in der Lage bist, ein paar Werte zu addieren - das ist hier nicht das Problem. Das Problem ist die Rolle von ENBoost selbst Das ersetzt schließlich Skyrims Speicherverwaltung komplett und trickst die von Windows aus - möglicherweise ist also hier beispielsweise schon die Absturzursache bei der Verwendung von BSAs bei dir zu suchen. Mit BSA-Dateien ist die RAM-Auslastung höher, so weit, so normal. Aber es sollte aufgrund dieser RAM-Auslastung gerade mit ENBoost niemals zu speicherbedingten Crashes kommen - denn schließlich ist sein Job ja durch eben die Aufteilung des verwendeten RAMs nach knapp 4 GB, genau diesem Problem entgegen zu wirken. Wenn dein Skyrim nun bei der Verwendung von BSAs crasht, das gleiche aber nicht tut, wenn du Lose Files verwendest, trotz ENBoost, dann gibts zwei Möglichkeiten, die mir einfallen:

1. das Umlagern des Speichers zwischen den diversen Prozessen funktioniert bei dir nicht fehlerfrei und der Crash wird so indirekt durch ENBoost selbst verursacht. Oder dadurch, dass der physische RAM nicht ausreicht, um alle ENBHost-Prozesse ordentlich unterzubringen (aber das dürfte bei einem Peak von nicht mal 6 GB eher nicht der Fall sein). Lose Files belegen weniger oder gar keinen RAM, deshalb muss nicht so oft umgelagert werden, weshalb das Problem nicht auftritt
2. das Problem hat mit dem RAM nicht das Geringste zu tun, sondern allein der VRAM-Bedarf ist schuld

Ich tendiere hier eher zu Möglichkeit 2, was aber nach wie vor die Frage aufwirft, warum bei dir der VRAM-Bedarf überhaupt so extrem unterschiedlich in einer vergleichbaren Situation ist. Ich weiß, dass ENBoost ein paar Fixes in diesem Bereich anwendet, kann aber nicht genau sagen, was es in der Hinsicht tut. Was ich aber ebenfalls weiß, dass egal ob BSA oder Einzeldateien in dieser Situation schlicht die gleichen Daten in deinem VRAM sein sollten - bei der BSA werden sie eben vom RAM aus dort abgelegt, bei Lose Files von der Platte ausgelesen. Das macht potentiell einen Unterschied in der Geschwindigkeit, aber es sollte keinen in der Menge machen - die VRAM-Auslastung sollte also gleich bleiben.

Aber selbst wenn sie das nicht tut... was tut eine Grafikkarte, wenn der Texturspeicher voll ist? Richtig, sie schiebt die Daten, von der sie glaubt, dass sie gerade nicht benötigt werden, aber bald wieder Verwendung finden, zurück in den RAM (völlig egal, ob Lose Files oder BSA). Das gibt in diesem Moment eine kurze, ruckelige Phase, aber sobald der Speicher frei und mit den neuen Daten belegt ist, ist es auch wieder gut. Das sollte ebenfalls weder dauerhaft die Performance beeinträchtigen, noch zu Crashes führen. Irgendwas ist hier also faul...

Ich glaub, ich muss das mal selbst beobachten, allerdings mit der SSE, OldRim ist nicht mehr installiert. Wenn BSAs grundsätzlich wider jeglicher Logik mehr VRAM belegen sollten läuft da nämlich was ganz Grundsätzliches bei Skyrim schief.

 

Die Reihe der Missverständnisse scheint noch nicht beendet

Absturz bei mir? Ich habe aktuell keine mit oldSkyrim. Wenn Du Dich auf die Kurve in der Grafik oben beziehst: der Abfall ist bei CTL-TAB aus dem Testspiel raus.

Der VRam-Bedarf bedingt bei Erreichen der physischen VRam-Menge ein Auslagern/Nachladen, und das wird m.E. durch skyrim.ini
bPreemptivelyUnloadCells=1
aktiviert. Kann man auch sehr deutlich ingame sehen. Wenn ich bei meiner Teststrecke via Ebental laufe, wieviel neu reingeholt wird. (Ich habe uGridsToLoad=7 )

Der Unterschied BSA und Loose ist dabei ein anderer: Es sind bei BSA von der CPU bei entsprechedem Ram-Bedarf ja 3 Operationen zu machen: BSA öffnen/dekomprimieren, vergleichen mit vorhandenen Files (weil die Vorrang haben) und Anlegen eines internen MFT, damit das Programm nicht jedesmal pro File erst auf der Platte und in die Master schauen muss (= erneutes Dekompromieren/Einlesen), ob mit Vorrrang da ist. Gleichzeitig werden die benötigten Files (zu denen es keine mit Vorrang auf der Platte gibt) von BSA ins Ram oder VRam geladen. Ist das insgesamt bei VRam mehr, als dessen physische Grösse erlaubt, kann bereits beim Laden ein wiederholtes Entladen/Nachladen erfolgen. (Bei Ram gibt es das so nicht, wenn davon zu wenig, dann CTD) Die gleichzeitig zu ladenden Scripte können dabei weiteres Umschichten bedingen (z.B. Drachenangriff sofort = weitere Grafik mit Animationenen, viele rumrennende NPCs in der Zelle). Alles ist für sich genommen wenig, aber alles zusammen kann die Grenze dann überschritten werden, mit CTD als Folge beim Laden (oder bei Schnellreise, was ich früher bei Open Cities und Schnellreise nach Rifton öfters beobachten konnte, aber nur bei Schnellreise nach Rifton!).

richtig, aber die vorherig oder gleichzeitig ablaufenden anderen Prozesse sind mit BSA eben anders bzw.mehr.

Deutlich auch testbar bei z.B. Summerset Isles mit BSA und als loose Files. Hier kommt nämlich noch hinzu, dass das BSA hoch komprimiert ist (im Gegensatz zum BSA bei Grey Fox of Nocturnal, das überhaupt nicht komprimiert ist). Bei 3.5 GB BSA-Inhalt also CPU-Leistung und Rambedarf und, weil die Files überwiegend nicht auf der Platte sind, oder in einem Master, auch VRam.

Hoch komprimiert ist z.B. auch HighResTexturePack02.bsa mit 1831 MB als BSA, was als loose Files 5360 MB hat. Also bereits hier Auswahl notwendig, was in der/den zu ladenden Zellen + den dort ablaufenden Ereignissen (scripts u.a.) aktuell gebraucht wird.

D.h., je mehr grosse komprimierte BSA und Scripte, desto mehr Hintergrundopertionen und aktueller Rambedarf. Vorteil bei BSA: einfache Installation/Deinstallaton und flüssigerer Ablauf bei normaler HDD, sofern ausreichend Ram und VRam vorhanden (weniger Ruckeln).

Der Vorteil schwindet bei einer SSD mit Momentum Cache (was wiederum Ram verlangt) und Grafikcache der Graka, wie bei meiner NVIDIA möglich (wobei hier ein Unterschied zwischen oldSkyrim und Skyrim SE ist. Das teste ich gerade). D.h. eine Mod kann als loose Files flüssig laufen, als BSA aber crashen (wie eben bei mir das Summerset Isles). (So laufen z.B. auch Death Mountain 1 + 2, trotz riesigem gleichzeitigen Aufkommen von Drachen und anderen Gegnern, völlig problemlos und praktisch Ruckelfrei mit oldSkyrim. Hab das mit 5 Begleitern gespielt, problemlos)

Dabei ist uGridsToLoad noch ein weiterer Faktor. 5 ist Default, 7 machbar, mehr ist schon kritisch.
uGridsToLoad=7 ; 5
uExteriorCellBuffer=64 ; 36 bei uGridsToLoad=5
iPreloadSizeLimit=51380224 ; 26214400 bei uGridsToLoad=5
bPreemptivelyUnloadCells=1 ; 0 wenn nicht oder 1 wenn geleert werden soll

Das gilt alles für oldSkyrim. Bei Skyrim SE gibt es kein ENBoost, da ist die Verwaltung anders, das Gesagte so nicht voll gültig. Da ich ja beides installiert habe, kann ich das gut vergleichen.

 

Bis du ungläubig wegen meinen Rechtschreibfehler oder der Schlangenöl-Software?

Wieso Einfluss auf VRAM? Ich verstehe die Funktionsweise von ENBoost so: bei DirectX 9 werden die Texturen in den Arbeitsspeicher gespiegelt. Und zwar in den Speicherbereich von Skyrim. Mit ENBoost werden in den Speicherbereich von ENBoost.

Faszinierend! Aber warum schreibst du das?

TES Spiele funktionieren nicht so wie man es sich denkt. Beispiel die Ghost Funktion von Wrye Bash bei Onlivion.

 

War wohl der Rechtschreibfehler "Schreib Cash"

Ich meine, dass Dreifels Platte bei jedem schreiben auf die Platte "Cash" nimmt und nicht einmal eine Kartenzahlung akzeptiert, ist wirklich nicht sehr glaubwürdig. Das musst du zugeben.

 

Ich bezog mich hierauf:

Weil ENBoost selbst, neben der Sache mit dem Auslagern bei zu vollem Arbeitsspeicher auch sonst noch ein paar "Fixes" anwendet. Du kannst ENBoost ja auch völlig ohne beispielsweise die ENBHost.exe betreiben. Hängt halt davon ab, was in deiner ENBLocal.ini aktiviert ist und was nicht - aber "direkt" weitergegeben in Form von gespiegelt bzw. unverändert umgeschichtet werden die Daten wohl nur sehr selten.

 

Denk da noch mal drüber nach (Ich wil jetzt und hier keine Diskussion über DX9 und Speicheradressierung lostreten)

dann verlgiech mal mit den Screenshots.

Übrigens: entdeckte Schreibfehler dürfen behalten werden. Sagt mal Danke.

Du hast leider ohne Link zum Thread zitiert. Damit der Zusammenhang nicht nachschaubar, ob hier relevant.

ich denke: gar nicht. Denn sonst müsste es eine Ram-Erweiterung sein, adäquat shared Memory, bei dem die Graka direkt auf Ram zugrefen und sich einen Bereich reservieren kann. Dazu muss die Graka aber designed sein. Dann würde der Breich auch nicht dynamisch wachsen, sondern fix definiert sein müssen.
Also erfolgt nur ein "Zwischenlagern" und wird der Graka dann bedarfsweise übergeben.
Die Besonderheit von ENB ist dabei, dass es die 3GB Grenze überspringt, was Skyrim selbst nicht kann. (Wobei z.B. auch das Kompilieren der Shader ja nur die Graka machen kann, was bei einem Shadercache der Graka dann geparkt wird. Das kann ENB nicht.) Fragt sich dann noch, wie bei einer grossen BSA ENBhost.exe und TesV.exe mit dem internen Entpacken und Table erstellen umgehen. Ich denke, das ist nur TESV.exe möglich, nicht ENB. Also speichert ENB "bei sich", was TESV.exe ausgelesen hat.
Und damit wird m.E. dann auch klar, wieso eine sehr grosse und hoch komprimierte BSA mehr belastet, als eine BSA ohne Komprimierung oder gar loose Files.

 

Dieser Thread? Eingangsposting?!


Und der Rest ist soweit völlig klar. Unklar ist nach wie vor der erhöhte VRAM-Bedarf. Das BSAs merklich mehr RAM belegen ist völlig logisch. Etwas mehr CPU-Zeit ebenso. Weniger Festplattenzugriffe auch.

 

ok, wieder gefunden. Wieso das bei loose Files weniger Vram belegt, kann ich nur vermuten, ich war auch über die Beobachtung verblüfft:
Wenn ich richtig liege, dann ist bPreemptivelyUnloadCells=1 ja der Zeiger für "weg, was nicht mehr gebraucht". Bei loose Files geht das fileweise, bei BSA nicht, sondern erst, wenn die Speichergrenze der Graka erreicht ist. Dafür spricht, dass bei loose Files relativ konstant immer mehr "Abstand" zum Limit gehalten wird, als bei BSA.. VRam-Belegung bis 4092, bevor was raus/reingenommen wird, also hart am Limit, kommt bei loose Files praktisch gar nicht vor. Bei Loose files sind öfters VRam-Schwankungen, aber immer kleinere Werte und mit "Abstand zum Limit".
(Ich werde die Tage mal spasseshalber alle bas, auch die Skyrim.bsa, auspacken und mal sehen, was dann abläuft. Also alles als loose Files. (Sind dann ca. 350.000 Files) Ist bei einer SSD ja easy, ist der ja egal, ob 1 grosses oder 1000 kleine Files. Dann kommt der Momentum-Cache auch richtig zum Tragen. Alles zusammen dann ca. 20GB Ram-Bedarf geschätzt. Ist dann wie gesamtes Spiel in Ramdisk und der Vorteil bei BSA mit weniger Festplattenzugriff ist dann auch weg. Mal sehen, ob meine Theorie stimmt)

 

Oldrim ist ein 32 Bit Spiel, sowas wird nie passieren, wenn sowas eintreten würde, dann wird nichts mehr im RAM gelagert, sondern auf der Festplatte gespeichert, dadurch wird ein flüssiges Spiel unmöglich.
Hast du dich hier verschrieben und meinst du Speicherplatz? 20 Gb RAM-Bedarf klingt ziemlich sinnfrei.

Soweit ich weiß ist sequentielles Lesen (eine große Datei) immer schneller als 4K random read (viele kleine Dateien) auf aktuelle Hardware, egal ob SSD oder HDD. Ob man den Unterschied merkt, sei dahingestellt.

Statt Oldrim zu testen, teste diese Sachen lieber mit der SSE und teste bei Oldrim ohne ENBoost.
Ich habe nämlich selbst bei Fallout 4 getestet und dort gibt es wesentliche Größere BSAs und das gleiche habe ich auch bei der SSE getestetet und konnte keine signifikanten Veränderungen feststellen, weder gibt es CTDs oder eine sehr hohe CPU Auslastung. Klar BSAs brauchen mehr Rechenleistung von der CPU, aber von welchem Bereich reden wir hier 3%? Alles läuft genauso flüssig wie vorher auch.

 

ich sag mal so...im grunde is es eh immer besser lose daten zu haben gerade so als modder....es sei den man hat irgendwelche mods mit unschönen ordnern oder alt oblivion daten struckturen ...stoti's pack is in Darkend und in Beyond Reach beidermassen vertretten und keine anung ob die sich gegenseitig überschreiben
ich zumindestens find das eher zum vorteil wen ich immer schnell an die DDS files rankome
was das laden angeht bin ich überfragt im grunde geht das mit heutiger hardwahre recht flott

 

@NewRaven

Quelle Microsoft Dank an @Xgf
Und hier ein Beispiel klick Dank an @FortuneHunter

Ich brauch nicht zu denken Ich habe den Artikel von Microsoft gelesen
Du brauchst dich nicht zurückhalten - wir wissen wir gerne du dein Wissen mit uns teilst.

Es gibt keinen Zusammenhang zwischen der Größe einer Datei und der Speichermenge die ein Prozess verwendet.

Der Wert "Größe auf Datenträger" ist ungeeignet für einen Vergleich. Eine Datei kann einmal 0 Bytes und woanders 4 kB haben.

Danke das du dich verschrieben hast

Die Shader werden von der CPU kompiliert. Siehe NVIDIA Systemsteuerung > Globale Einstellungen oder hier

Die Software kann nur kurzfristig "das Schreiben" auf die SSD Beschleunigen und nur für eine begrenzte Datenmenge. Datenblatt

 

sorry, aber das ist alles völlig falsch, nichts begriffen.
Win7/64 und andere Systemfles etc. nehmen ca. 2GB RAM
EMBoost kann bis zu ca. 10GB = RAM Bedarf, ENBoost schreibt nichts auf Laufwerk
MomentumCache belegt bei mir dynamisch bis zu ca. 8GB RAM (kann mehr)
Gesamtbedarf an RAM in der Spitze = ca. 20GB RAM
Die Schreib-/Leseoperationen auf der SSD werden durch den MomentumCache deutlich reduziert. Das ist vor allem vorteilhaft bei häufigen kurz aufeinander folgendem Zugriff auf dieselben Files, also typisch bei einem Spiel wie Skyrim. (Ausserdem verlängert MomentumCache die Lebensdauer einer SSD, geht aber nur, wenn auch Akkubetrieb, also z.B. Notebook.)

Der Sinn von ShaderCace bei der NVIDIA ist abhängig von der Rechnerhardware (Da wirkt MomentumCache übrigens auch, wenn das auf derselben SSD gespeichert wird)

http://www.overclock.net/t/1553142/shader-cache-setting #9

The deal with shader cache is that is designed to store compiled shaders. The process to initially compile the shaders uses CPU cycles.

This means depending on many factors, shader cache can help or hurt performance.

Examples:
»» If the CPU is fast enough and the shaders are simple enough, you might compile the shaders in real time faster than it would take you to read a previously compiled shader from a slow hard disk. There could even be instances where the CPU compiles in real time faster than reading from an SSD.

»» Same scenario as above, but the shaders are complex.. This makes the same scenario potentially provide different results if the CPU penalty is significant to re-complile a complex shader in real time. In this scenario it could help, assuming the storage is fast enough to be read from.

»» A slow CPU may not be able to compile even a simple shader without impacting frame rate which is sometimes why we see that some games start out a bit choppy and 'smooth out' over time after cache of the game engine comes into play. If the game engine doesn't offer caching then NVIDIA might help smooth frames. If the game engine does offer caching, NVIDIA may possibly assist, or negatively impact the frame rates/frame times.

»» GPU memory limitations. If there is simply very little GPU memory there may be no choice but to swap things to disk, otherwise the game/app may not run at all.

IMO I think the answer really DEPENDS, and that is also why it seems to help in some games/applications but not others. I wouldn't just disable it for all, you CAN configure this setting per game using the program settings of NVCP

Nvidia GeForce Tweak Guide

Im Übrigen: Hier geht es um oldSkyrim. Skyrim SSE ist hier kein Thema
Wer das diskutieren will, möge einen eigenen Thread eröffnen.

 

Tut mir leid, aber begriffen habe ich sehr wohl. Dennoch verwechselt du hier RAM und VRAM, wirfst auch noch alles zusammen. Ein 32 Bit Spiel wird nicht in der Lage dazu sein. ENBoost umgeht dies mit einem Trick, aber ich weiß nicht wo du die 20 GB hernimmst. Wenn das Spiel 20 GB verbraucht, dann wird auf der Platte weitergeschrieben, falls du nicht genügend RAM hast. Ansonsten ruckelt es nur noch. Daran ändert weder ENBoost noch irgendein anderes Tool etwas. Das ist Allgemeinwissen beim PC.
Du addierst einfach Zahlen. Weißt du, was du da tust?

Mittlerweile habe ich begriffen, was du meinst. Verbrauch ≠ Bedarf, jedoch wirfst du hier sogar Bedarf durcheinander. ENBoost kann die Limitierung aufheben, jedoch bedarf es keine 10 GB dafür. Wenn deine Festplatte 8 GB RAM belegt, haben wir doch jetzt die Ursache gefunden, hier bringst du aber auch noch Cache und RAM durcheinander, ich habe noch nie eine Festplatte gesehen, welche 8 GB vom RAM belegt. Dann rate ich dir von einer solchen Platte eher ab. Soweit ich weiß hast du doch nur 16 GB RAM?

Hier geht es nicht nur um Oldrim, sondern allgemein darum, wie diese Szenarien zustande kommen. Es wäre auch ein guter Vergleich.
Kannst du nicht sowas lassen?

Damit machst du dir weder Freunde noch tust du der Disskusion etwas Gutes.

Bitte zeig mir doch mal deinen 20 GB RAM-Bedarf.

 

Quelle

Davon steht nichts in Datenblatt - also falsch.

Sich mit fremden Federn ist nicht die feine Art @dreifels

 

Im Datenblatt steht nicht alles. Das Installationstool verweigert die Installation, wenn keine Netzfreie Stromversorgung (Akku) entdeckt wird.
Also richtig.

@Licht
zu Deinem besseren Verständnis:
von links: Cruicial mit MomentumCache (Spiele, TMP, TEMP, ShaderCache) - OCZ im DVD-Slot ohne Cache - Samsung (Boot, System, Windows) ohne MomentumCache

 

@dreifels, und was sollen mir die Bilder sagen?

 

Ich vertraue mehr den "falschen" Datenblatt als deiner Erfahrung. Es wird in keinen Artikel genannt, es macht keinen Sinn, du machst zu viele Fehler, deine technischen Kenntnisse & Verständnis,..

@dreifels du solltest wirklich anfangen deine Beiträge verständlich zu schreiben. Also so:
SDD (Crucial_CT525)
SSD (SAMSUNG MZ7TD)
Schreib nicht geläufige Abkürzungen beim ersten Mal aus; was soll OCZ sein?

 

Auch wir haben jetzt hier aneinander vorbei geredet. Mir ist durchaus klar, wie Daten letztlich in den VRAM kommen und wohin sie wandern, wenn selbiger voll ist. Hier ging es aber um ENBoost und darum, ob dieser zwischengeschaltete Prozess, der dazu dient, das Speicherlimit des Skyrim.exe-Prozesses zu umgehen, diese Daten 1:1 unverändert so verarbeitet, wie es Skyrim selbst standardmäßig tut. Und das ist nicht der Fall, dass ist nicht mal mehr für Skyrim selbst der Fall (also ohne ENBHost), sobald ENBoost aktiv ist. Kern meiner Aussage ist: solange ENBoost aktiv ist, kannst du, eben aufgrund der veränderten Datenstöme, nicht wirklich eine Theorie aufstellen wie: BSA-Assets belegen meinen VRAM mehr als Lose Files.

Ich hab das jetzt, allerdings bei der SSE, auch nochmal getestet und eine derartige Abweichung wie @dreifels konnte ich zu keinem Zeitpunkt feststellen... eigentlich konnte ich sogar gar keine Abweichung im VRAM-Bedarf feststellen, die sich nicht mit Messtoleranz bzw. der Tatsache, dass ich die Szene nicht 100%ig exakt nachstellen konnte, erklären kann.