Salvador

If using 0.204' date=' yes. Max you should use is 512. The lower you go, the less stutter, however, the higher a chance for freeze or CTD, but you need to go really low for that. Try 384 and see how that goes. You need to find the sweet spot really, which if dependant on your mod list and hardware.[/quote'] Why are the values lower than they were for 0.200 - 2.202? Because Boris changed the memory manager, and added dynamic unloading of the VRAM. Which means if less than 64mb free VRAM space is left it automatically unloads a bunch of data. Naturally this means that only really big memory spikes cause a problem. However, I just follow his words and advise, as I have no clue what goes on under the hood in the d3d9.dll and Enbhost.exe. He said this version needs lower values with 512 max. With 0.204 I can load saves with ReservedMemorySizeMb=128 that I couldn't load before with anything lower than 640 (the saves my wife uses, she uses tgm and carries loads of items). I also have less stutter now.

If using 0.204, yes. Max you should use is 512. The lower you go, the less stutter, however, the higher a chance for freeze or CTD, but you need to go really low for that. Try 384 and see how that goes. You need to find the sweet spot really, which if dependant on your mod list and hardware.

Version 0.204 runs a lot better for me. You can set the ReservedMemorySizeMb= really low on this version. Simply backup your current dll file, you can easily switch back.

I've send the message. This mod has gone crazy in just 24 hours. I waited long for someone else to make it. i shouldn't have waited.

Hi, I am the author of the SkyFalls mod. It works really nice in combination with SDO. And no, SDO does not animate distant waterfalls as the "is full LOD" tag doesn't work for the original static waterfalls. I had to replace all waterfalls with FX files in order to make them full lod. There seem to be some minor issues left with some other exterior World (not tamriel) waterfalls, that seem to bug when the is full LOD box is ticked but I am ironing them out, they are simple to fix. Nice to see someone at STEP picked it up. Uploading a mod like this is more work than I anticipated. But it certainly fixed a terrably ugly vanilla game issue.

Hmm, I used Skyrim performance monitor (works with latest) and simple windows system monitor?...I don't see a lot of difference but I have AMD graphics. He is still working on that. 20 versions? did you test all his 0.193 test versions? You need 0.193 DLL. Everyone on the enb forum sees major benefit. I will try VMMap and see what happens... The only thing that is annoying for me is that the Graphics card is used maximally now (you do need more than 1Gb VRAM to see a difference though!) so much so that the sound it makes becomes really annoying (seems to be a good OC stability test though). Hence I play without the performance tweaks for now.

Just try with latest enb and set all memory options to true in enblocal.ini Without the ini, nothing happens, hence he also published a guide to adapt old presets to the new 2 ini files system. I assume you did that?

Hi Kuroyume, Apologies for my late reply. I still promised to make screens, you still want some? Or anyone else? Glad you like it! Performance wise it has a very small impact. Just test with pause/break button. If FPS goes up it is Immersive environment stealing 2 or 3 FPS. As I am using ENB I use its integrated EdgeAA which has no performance impact. But ofcourse the rest of the ENB mod has a lot of performance impact. I might stop using it, it was only for the effects anyways (even on barely modded Skyrim I sometimes go down to 30 fps...). Before I used ENB, I forced 8x MSAA through the driver (AMD) and set in the ini to 8x as well. Don't know what is best. Performance wise, setting it in ini and than set in CCC to improve game AA instead of overwrite gave best performance. I use FXAA, looks ugly without Immersive environment, but in combination works quite nicely, just smooths the edges a little. I am sure you will like CoT. I do not use any of the dungeon or interior parts though. I do use darker nights 1. You can go darker if you prefer. I like some visibility but not too much, it gives you the feeling it really is night.

I tried this ini tweak, and I liked it. However, no tint and desaturation is similar without any performance impact either. Now just slightly off-topic: Personally I am addicted to Immersive envrionment. I have tried everything. I love RLO, but I just cannot do without Immersive Environment, and those together become too dark (you can probably fiddle with this, but as a perfectionist it would take me way too much time). So what I have now, for those who are interested to give it a try, is: CoT darker nights 1, skyrealism vanilla enb v0.153 (optional, just for SSAO, shadows and skylight), Immersive envrionment and Relighting Skyrim. Then, if you use the enb up the brightness a little (not needed without the enb, but this is of course personal) This IMHO looks best of all I tested (ELFX, RCRN (3.6 and AE beta), RLO, CoT, no tint, Vanilla at its best and all possible combinations thereof, with and without enb) Without the enb, I do not take even the slightest of performance hit (2500K and 6950 2GB). Installing and uninstalling immersive environment is so simple, I urge everyone to just give it a try, make sure to use pause button to see the actual difference in-game. I used it since version 1.3 and have yet to find a better lighting/color/atmosphere solution. I will post some screens when I am up for it. Reinstalling everything at the moment, so that should be possible soon.

I can't resist to post this here. However, if considered against forum rules please remove or edit this post. Plea for help from Tony (sydney666)

One of the people in this thread crashes with 1200mb VRAM. Whilst Neovalen can run perfectly fine with 2900VRAM with half sized normals. How much of the VRAM is allocated by Skyrim is impossible to find out. But all that is allocated by skyrim as locked (not to be swapped out in case of need) is duplicated within RAM (allocation, not literally copied, but since their is a 4GB allocation limit, it is still a heavy burden) This duplication is used if you alt-tab out of the game. It copies all locked VRAM to RAM, and back when you alt-tab back in.

Yes that be interesting to test, I also wonder how much screen resolution plays a role. What I understand from this thread is that you can get pretty low VRAM usage and still crash and have high RAM usage. allocated VRAM is part of address space and as all locked pages in VRAM are copied in RAM, this would suggest to me, that all loaded normals are locked. Because if you reduce normals you hit very high VRAM, but no problems in game. however, leave normals alone, and do simple optimization, or use lower resolution textures, and you can crash with low VRAM usage. We should test this. Load very low textures with high normals and visa versa and measure both VRAM and RAM.

Would be interesting to see how the sound mods affect memory. Although ENB does not load much in RAM. How about VRAM? Any VRAM allocation used from software based AA is also part of skyrim address space. AA is a big VRAM user (normally, perhaps Boris did good optimizations). Yes any DLLs in skyrim root are loaded within its address space. Would be interesting to see how much VRAM/RAM ENB or SMAA use, most probably a lot less than the driver (hardware). However if you have plenty of spare VRAM, you would be better off using forced driver settings. I figured you have 4GB card? so VRAM limit is not a problem for you. (This is ofcourse VRAM wise, the performance impact of hardware based AA (or AF) vs ENB or SMAA is not considered here) Yes it is a shame cheese wedges don't work. I don't understand the ATTK stability improvements either, would be good to ask Jason2112, he knows a lot about memmory.Â

Hi Viking and Z. To start with, I tried the Cheese wedge things on vanilla skyrim with texture packs. Only increases memory usage by couple mb. It does gradually increase CPU usage though. There is no difference at all in VRAM, as expected. So it does not load any RAM clearly. You can however freeze your game, just try 800 cheese wedges 3 times in a row (I was on high hrothgar). I wonder why ATTK helps so much (you can do many more cheese wedges) if it uses relatively little memory?... Therefore you need some other memory intensive mods that do not touch textures, to see if it really is textures, or something else that makes it cap at ~3GB Perhaps some large sound files attach to a certain location? My interpretation. Apparently only part of the VRAM you will see in process explorer (or GPU-Z) is actually part of the virtual address space that is used by Skyrim. At least that is how I interpret the documentation from Microsoft that MontyMM linked to (and this, although perhaps not fully reliable). Most of the memory is allocated to the driver for AA etc. "The game does not need to know about the memory used for AA calculations. This happens in memory space that is not a part of the games 32 bit address space. How can we be certain of this? Well, you can force AA at the driver level, and the game will never know it's running AA. This is handled by a different application, and while I suspect this memory space would be subject to the address space limit of a 32 bit OS, it should not be an issue for a 32 bit app in a 64 bit OS."Â This would suggest you can save some memory by using driver AA above Skyrim or ENB AA etc. Now, from the link MontyMM provided it is clear that the data loaded into VRAM by a process was copied in RAM, and the copy was maintained, taking up address space and essentially doubling memory allocation. However, this was fixed for DX10 and above. This is however partially fixed for DX9. You need to understand which part of that memory is allocated as locked. In other words, Skyrim doesn't allow it to be swapped out. Only this allocated video resource is copied into RAM and part of the allocated virtual memory address space. The remainder is not. Say skyrim allocates 512MB VRAM, it only has 3.5GB allocation left. However, in the past the full used 512MB was copied in RAM, leaving only 3GB. To overcome this (partially) windows makes sure only part of the 512MB is copied (the locked part) say 256MB is allocated as locked pages, that part is copied into RAM, leaving 3.25GB of allocation space. This provides a new problem. Dynamic VRAM (or system VRAM) is RAM allocated as VRAM (hypermemory (AMD) or TurboCache (Nvidea)). Is this addressed by the skyrim engine? if so, than it takes up address space. This is not necessarily loaded with locked allocations, and might therefore be loaded with unlocked pages. If the dynamic VRAM is loaded with lockable pages by Skyrim, it is also duplicated and loaded again within skyrims address space. But I fully agree, to find any evidence of textures taking up RAM space for skyrim, you should measure VRAM spillover and Skyrim memory allocation. you should see a Skyrim memory usage increase similar or proportional to the increase in dynamic VRAM by only increasing texture size.

Same here. Gonna test the cheese wedges right now. See how much mem they take up in vanilla skyrim.

I'm assuming for a moment that the RAM limit crash does exist. What I'm curious about is whether it might be the Skyrim engine deciding to cache the textures in RAM (in which case there is the slight possibility of this being configurable) or whether this is certainly an inescapable behaviour of DX9. There might be a techie around here who can testify. Yes this is how I read it as well. There used to be a full copy of the allocated VRAM in physical memory. With DirectX10 this is handled by WDDM and thus no longer takes up space in the virtual memory allocation. If an application creates its own in-memory copy of its video resource OR uses Direct X9, they still produce a copy. Memory is lockable or not, in other words, it cannot or can be swapped out and make space for other allocations. The VRAM that is normally tagged as able to be swapped out (unlocked) (hence real VRAM cap is higher than when all VRAM is allocated), is not copied into virtual memory space. Now we need to figure out what is written as locked. Perhaps Jason2112 can help out? EDIT: I should say written rather than copied into virtual address space. I do wonder how that works, because basically it means that the process can use considerably more VRAM, as it is no longer considered part of the address space....?

I think this is a key question. The wording in the KB article (attached to a hotfix), suggests that Windows itself was modified to improve the problematic memory allocation of DX9: If an application creates its own in-memory copy of its video resources, or the application uses DirectX 9 or an earlier version, the virtual address space contains the WDDM video memory manager's virtualized range and the application's copy. Applications that use graphics APIs that are earlier than DirectX 10 and that target GPUs that have large amounts of video memory can easily exhaust their virtual address space. To address this problem, Microsoft is changing the way that the video memory manager maintains the content of video memory resources. This change is being made so that a permanent virtual address range does not have to be used for each virtualized allocation. With the new approach, only allocations that are created as "lockable" consume space in the virtual address space of the application. Allocations that are not created as "lockable" do not consume space. This approach significantly reduces the virtual address space that is used. Therefore, the application can run on large video memory configurations without reaching the limits. This seems to leave open the question of how much of Skyrim's memory texture caching is inherent to its DX9 origins, or a (possibly configurable) feature of the engine. Perhaps someone knows with certainty the DX9 memory behaviour on later versions of Windows? Install skyrim on XP x64 with only DX9 installed and see if it runs. If it does, it certainly doesn't use DX10. What is defined by lockable? And is all allocated VRAM allocated by Skyrim? Or part (as I assume) by the driver to process the images.... Would it make a difference to run AA through driver or through skyrim? Would this be a separate process? ENB DLL (and therefore I assume AA through Skyrim) takes up memory in the skyrim process for sure. EDIT: Says on the box, DirectX 9c video card. So no DX10, although I am sure most people already assumed so. Windows did fix allocation. Now the full 2GB isn't mirrored anymore, but the mirror increases with VRAM demand from the process. But apparently that is dependant on "Lockable" allocation EDIT EDIT: apologies, VRAM is part of the allocated virtual memory space. And all "lockable" allocations take space within the allocated virtual memory. However, VRAM used by the process is mirrored in RAM for DX9. The question now remains. Is all lockable allocated VRAM mirrored? What is lockable?

I fully agree. Would be nice to see memory hogs that do not increase textures. That way the mirroring can be tested... The benchmark the guy used for testing ATTK was cheese wedges. These are duplications, and therefore require no additional textures or VRAM presumably. But their havoc needs calculations and thus a lot of memory. Is that an idea? BTW I couldn't find the link about the prefetch stuff I was talking about, I know it was from Mark Russinovich and this comes close. Although it is no longer shown in the task manager, that is still happening! EDIT: Perhaps not the best idea. The graphs that were provided by xeightballx show no or little increase in RAM usage (or CPU?), but he already reached his VRAM max. Also VRAM and RAM usage remained high, even though the game had crashed?

Hmmm, how did I got your name wrong?.. apologies. I believed it was DX9 only, yet Viking said it could partially be DX10. If DX9 only this means that all allocated VRAM to skyrim is mirrored in system memory. Yes I know it is all allocated and not necessarily used. But this should suggest, that any increase in dynamic VRAM (or system VRAM) is mirrored in RAM. Therefore, by just increasing texture sizes when you reached your VRAM cap, you could perhaps get an idea on how much is really mirrored (allocated. The problem occurs with 3.1GB allocated memory). However, I need to find the link, in original windows 7 RAM allocated by sytem was shown, and because of the improved pre-fetch, it had very high memory usage numbers, which upset quite a lot of people, so they changed that. So even the allocation numbers are somewhat incorrect. Edit: fixed names Since there is an absolute allocation cap at 4GB, and since allocation has improved considerably (read most skyrim updates), especially in combination with ATTK. You can argue that when you get CTD, you have used most of the allocated memory. If not, there is still room for improvement. Usually when the process needs to allocate more, it removes blocks (or pages) it believes it no longer requires. If it fails to do so, it is unable to allocate more.

Hmmm, how did I got your name wrong?.. apologies. I believed it was DX9 only, yet Viking said it could partially be DX10. If DX9 only this means that all allocated VRAM to skyrim is mirrored in system memory. Yes I know it is all allocated and not necessarily used. But this should suggest, that any increase in dynamic VRAM (or system VRAM) is mirrored in RAM. Therefore, by just increasing texture sizes when you reached your VRAM cap, you could perhaps get an idea on how much is really mirrored (allocated. The problem occurs with 3.1GB allocated memory). However, I need to find the link, in original windows 7 RAM allocated by sytem was shown, and because of the improved pre-fetch, it had very high memory usage numbers, which upset quite a lot of people, so they changed that. So even the allocation numbers are somewhat incorrect. Edit: fixed names

I see I'm slow with posting. @Viking As I liked the gamasutra link, due to the good references, I would love to know what is so misleading about it. It did indeed mis the info in the earlier link that showed that for DX9 only allocated VRAM is mirrored and for DX10 and 11 nothing is mirrored in RAM anymore (after fix). I believed Skyrim was DX9, but apparently it could be DX10 as well? both XBOX and playstation are DX9 only right? Or is PC version considerably different?

I shouldn't have used the term "pre-cached" since caching memory already implies a certain buffer. My point was to not get confused by the extra memory that would be cached in any case, any application may appear to use more memory than it actually needs, up until the point it runs out completely. You can't measure VRAM usage accurately, and that has been addressed a lot of times already. You're probably thinking about the extra textures that has been buffered to the video RAM, but aren't actually used by the engine. With regards to the memory limitation, Dx9 mirrors VRAM onto the system memory, in turn reducing your actual system RAM limit by the amount of VRAM in use for any process. Microsoft got rid of this limitation in DirectX 10. x86 processes with Large Address Aware patch can use up to 4GB total system memory. In other words, it's complicated. But it can be assumed that a crash would occur when Skyrim with LAA suddenly requires more than 4GB of RAM+VRAM. How to measure that point accurately is another matter. At least that's how I understand it. DX9 is partially fixed, and not fully mirrored anymore, but the allocated VRAM is (the part allocated to Skyrim (textures)) according to besidilo site link (which is really good, love the references). In short, for DX9 the allocated VRAM grows (and is duplicated in RAM) when more VRAM is needed by the game engine and thus more memory is used when more VRAM is allocated (compressed textures I presume). My understanding from your words, and from quickly reading through the articles is that you should also count the VRAM, at least the part of textures that is loading into VRAM. Not all the AA and AF and other processing going on in your graphics card that is also loaded into VRAM. So, from those 2.7GB only, lets say (just random example), a third are actually loaded textures, the remainder is used and allocated by the driver. However, I was under the impression that the driver handles VRAM allocation completely, which apparently is incorrect, or perhaps the driver sort of functions as the OS does for RAM when it comes to allocating VRAM for Skyrim. I know only limited tests are done. I never said everything or nothing is mirrored. In the past things were completely mirrored as can be understood from the literature such as besidilo points to. And now this is mostly fixed, apart from DX9 which is only partially fixed. However this does not explain how it comes you can continue to play when VRAM cap is reached. This would suggest that dynamic or system VRAM, is RAM allocated as being VRAM? If that is indeed the case, than that dynamic VRAM (if allocated to Skyrim engine and not the VGA driver) should also be duplicated. This would suggest that above VRAM cap your memory usage grows rather fast. Would be nice to see full RAM usage on Zs benchmarks. You'd expect that an increase in system VRAM of 200mb means a increase in memory usage of 400mb, could perhaps be a nice test to measure if there is mirroring going on. Love this thread and these type of discussions. Apologies to viking for changing the topic quite a bit.

Really, That is very interesting indeed.... but also worrisome. Because quite a bit of the VRAM is mirrored in RAM. This would suggest that DDSopting would have double the effect?... Unless Z is absolutely right and there is no mirroring going on. Nonetheless, DDSopt seems to be really important now. @ Viking Yes my bad, it should only page when running out of RAM, however, OS dumps quite some things in Page (that are not needed soon) to free up RAM. Processes can however address page file directly. Still, the process should be able to address 4GB of space with a 32 bit integer. Besidilo's post would suggest that the other 1GB is in VRAM. Isn't VRAM usage addressed by the graphics driver?Â

All good questions, but I would expect a game to crash or freeze if it had to start using page memory. VRAM is fast. RAM is much slower and causes stuttering in-game. However, page memory is extremely slow (especially on HDD)...slow enough that if RAM causes stuttering, a crash or freeze wouldn't come as a surprise for a game that called for something that was stored in page memory.Yes exactly, that is why I disable page on disk. It automatically allocates in RAM instead (However, you should only do this if you have plenty, and never run out of RAM). Together with page any large address aware 32 bit process should certainly be able to reach the 4GB on 64bit OS. VRAM is not limited for most people having issues on this thread. Their VRAM cap is not reached.Does Skyim use contiguous memory, or works in chunks? A different question. DLLs usually allocate quite a bit of memory. Does having ENB DLL present or not make any difference on mem usage, just disabling ENB does not stop it from loading into mem. Might also be interesting to see what the different DLLs do. I find it strange to see these discrepancies between people in the amount of RAM usage, with similar STEP installments.....