uGrid=9 with the LAA-launcher works fine for me (GTX 590), BUT I fear when the Bethesda patch comes along next week, all this ain't gonna work no more (steam patch piggy pack) and all my savegames with uGrid 9 will go south

Does this still all work after the Steam patch? I had issues with other .ini tweaks causing CTD straight after loading a game

If you read the first post made in this thread.. it's been updated to reference the newest Skyrim4GB Launcher which makes the LAA Patch obsolete and allows you to use mods and these settings just fine with the new and future skyrim patches that may come... Just follow the instructions.

I seem to have a problem. I was playing fne minding my own business when I got the idea to change the ugridstoload. I added the line and set it to 7. Tried to load the save, ctd. Cool, I thought, I'll have to change it back and do the save thing. Only, after I removed the ugridstoload line, my save still crashes. And keeps crashing to this second, after all I've tried. I set it to 5, crash. Set it to 7, crash. Remove the line, crash. Set it to 9 and it keeps loading forever. 11 loads forever also. So, anything. below 9 and I get ctd (with the line removed too) and @ 9 or above skyrim stops responding. The loading screen animations and sounds work fine but its just stuck there.
Help

My save seemed to have grids set to 9, figured as much as it wasnt ctd'ing with that. Had to delete both .inis then let the game recreate them.
Loaded up my save with 9, set it to 7 and saved the ini, works fine now.

I think skyrim loads some values from a temporary file or some such as the .inis I pasted back are 100% the same as when before the crashes (or indeed any change I would make didnt affect crashability before the recreation of the inis).

I recommend restarting your computer when you're about to test a new uGrid setting (just to 'free up' your memory completely). I was trying uGrid 11 and my game was crashing, so i set it back to 9 (which had been working fine for a few days) and it started crashing with that setting too... strangely enough it was crashing around the same time as with uGrids 11 (after about 5 minutes play time).

So i rebooted my computer and 9 started working fine again.

I've noticed this trend a few times when trying new settings, so if you've already been playing the game and you want to try a new uGrid setting I think it's worth rebooting first. Of course it doesn't mean the setting will work, but i think it gives it a better chance.

laa doesn't work anymore. use http://skyrimnexus.com/downloads/file.php?id=1013

yeah i updated the LAA post on the first post in this thread to ignore it.. and use the 4GB Launcher for skyrim

Can someone explain what the Exterior Cell Buffer actually does? It's just that i've realised i can use uGrid 11 if i lower the Exterior Cell Buffer to 64. I know this is well below the recommended value of 144, but the game seems to be working fine with this lower setting.

Up until now i was using uGrid 9 with 100 Exterior Cell Buffer, but uGrid 11 and 144 Exterior Cell Buffer caused my game to crash a lot. Now it seems stable, although i might just have been lucky.

So is the Exterior Cell Buffer important, and should it really be that high? Maybe by using settings of 100 and more we are asking the game to load more into memory than it actually needs to, and therefore it is running out of memory and crashing.

Just thought i should report this finding, as it might help others to use higher uGrid settings as well.

Actually i might try uGrid 11 again but this time just remove the Exterior Cell Buffer line altogether... I'll report back..

Scrap that last post - my game is crashing all the time now with uGrid 11... i think i just got lucky before as using Exterior Cell Buffer 64 isn't working anymore..

at first i thought you were onto something and was about to go try a few things.. as i was positive that trying to keep the same small exterior buffer with high ugrids was resulting in instant crashing before...

then you posted again..

aww..... lol

Hi O.P.

I've gotta say: What are you talking about in more understandable, non-technical terms?

I thank you for fixes and such but Can you "break it down?"

Thanks....Btw, I have an A.S. in Comp. Tech.!

I ask not for me, but for others......its lots of writing you put out bro

I'd like to assist stefnuts... but i really haven't a clue how to break it down any further... i tried to lay it out as nicely as possible.... as easy to read and clear/directions as possible too...

lol... yes i thought i was onto something as well.

It certainly doesn't cause instant crashing though - using the lower Exterior Cell Buffer with high uGrids actually doesn't crash any more often than it does when using the recommended cell buffer value, in fact it might crash slightly less (on my system at least). I'm definitely going to test things further, but last night i had to give up and go to bed.

A lot of people might be thinking "who cares if it crashes slightly more or slightly less - it's still crashing?" but i'm one of those people who likes to know why things are happening, and if something makes the game crash 'slightly less' then perhaps more testing will result in a way to stop it crashing at all. Then we end up with a better looking game to play!

Of course i think we are all seeing a certain lack of consistency with the game in general - sometimes a setting can work perfectly for hours, then the next day you're using the exact same settings and it will crash very quickly... stuff like that is really annoying when you're trying to test these things out.

Anyway, back to work...

Hi !

thanks for this post.
I've been experimenting *a lot* with the ini files, and I've found that it works better (for me at least)
if you leave the uExterior Cell Buffer parameter not set (ie, don't enter any value).
I'm using 9 grid cells, and I had systematical crashes at some places (where the game has to load
lots of stuff suddenly, like going over a hill...).
I removed uExterior Cell Buffer from the ini file, and it suddenly worked !

people might want to try this !

After extensive testing of uGrids I have determined that low FPS is not caused by extra GPU load but a problem with the game engine, well with my system setup anyway.

Basic System Info:
Intel i5 2500K OC 4.2GHz
8Gb DDR3 CL9 1600MHz
OCZ 60Gb Vertex 2 SSD (OS), 2x 500Gb Samsung Spinpoint F3 in RAID 0 (Games & Programs)
2x eVGA GTX 480 Hydro Copper FTW (not running SLI atm because my 3rd GPU that runs extra monitors doesn't fit with current Liquid Cooling setup so following results are of 1 OC GTX 480)


The results are from loading the same save then doing a 360 turn to load maximum surrounding area then looking at the exact same spot every time then taking GPU and FPS readings using FRAPS and GPU-Z, also this is using a custom ini with vSync enabled and only changes are uGrids and corresponding settings.

Default uGrids:
60 FPS
95% GPU Load & 40% Memory Controller Load
1338 of 1536Mb Dedicated GPU Memory Used

uGrids 7:
40 FPS
70% GPU Load & 30% Memory Controller Load
1381 of 1536Mb Dedicated GPU Memory Used

uGrids 9:
30 FPS
60% GPU Load & 23% Memory Controller Load
1411 of 1536Mb Dedicated GPU Memory Used

Screen of uGrids 9:
http://img204.imageshack.us/img204/1271/tesv20111127ugrids9.jpg

Screen Shots of GPU-Z and Process Explorer with Skyrim running uGrids 9, ignore the sudden drops at the end they are when I alt tab'd to take the shots and the numbers aren't accurate they are what it was at the time of the img taken the graphs are the important bit:
http://img220.imageshack.us/img220/764/skyrimcpuusage45totalug.jpg Green is Skyrim, Red is everything else on PC. Total CPU Load 60% & Skyrim 45%
http://img804.imageshack.us/img804/9619/skyrimgpuusage60gpu22me.jpg GPU Load 60%, Memory Controller 23%, Dedicated Memory 1411Mb


The interesting thing is not one part of my system is under much load when uGrids is set higher but I get lower FPS. CPU stays at approx 60% total load with Skyrim using 40-50% with none of the 4 Cores at 100% and there is no change in CPU load with uGrids at any setting, system memory is approx 6.4Gb with Skyrim using approx 1Gb with uGrids 9. I already knew about the low GPU load but then I noticed I'd maxed out my GPU Dedicated Memory but I had Photoshop running at the time so closed it and I gained a little over 100mb of GPU memory but the game didn't use it and stayed at 30 FPS so it didn't need more GPU memory to get more FPS so it seems there is a problem with the game engine as the higher uGrids goes the lower the FPS but also the GPU load drops but it should stay the same or go higher and then the FPS should start dropping.

Edit: Forgot to mention disabling vSync doesn't increase FPS or GPU load with uGrids set to anything but default.

thanks for the update....

Pala22, great data set!

Right 100% proof it is a game engine problem, new nVidia Beta Drivers 290.36 and I found an old GeForce 7300 LE that fits in system atm so enabled SLI.

Dual OC GTX 480 Core Clock 752MHz, Memory 950MHz in SLI, and because it's SLI both GPU's are running these loads.

uGrids 9:
31 FPS
31% GPU Load & 10% Memory Controller Load
1244 of 1536Mb Dedicated GPU Memory Used

uGrids 9 + nVidia Control Panel Settings:
31 FPS
58% GPU Load & 13% Memory Controller Load
1297 of 1536Mb Dedicated GPU Memory Used


nVidia Control Panel Settings

Ambient Occlusion: Quality
Anisotropic Filtering: 16x
Texture Filtering: High Quality
Transparency Antialiasing: 8x (Supersample)
Triple Buffering: On

Both are using the exact same ini settings as with previous post and at same clock speeds ect, but 2nd is using sum nVidia Control Panel settings to increase detail and Triple Buffering which should improve vSync performance.

i found with my system that if i use the new 4gb large address mod and

[Papyrus]
iMinMemoryPageSize=100000
iMaxMemoryPageSize=5000000
iMaxAllocatedMemoryBytes=1800000000

commands in the ini i get alot more crashing , i have solved this bye taking out those Papyrus ini commands ,and im just running the 4gb mod , ive had no crashes any more since i have done this , it seem that those Papyrus commands were restricting the 4gb patch to use full ram in my system..




[General]
sLanguage=ENGLISH

uExterior Cell Buffer=100
uGridsToLoad=9

[Display]
fSunUpdateThreshold=0
fSunShadowUpdateTime=0
fShadowLODMaxStartFade=1000.0
fSpecularLODMaxStartFade=2000.0
fLightLODMaxStartFade=3500.0
iShadowMapResolutionPrimary=4096
bAllowScreenshot=1


[Audio]
fMusicDuckingSeconds=6.0
fMusicUnDuckingSeconds=8.0
fMenuModeFadeOutTime=3.0
fMenuModeFadeInTime=1.0

[Grass]
bAllowCreateGrass=1
bAllowLoadGrass=0

[GeneralWarnings]
SGeneralMasterMismatchWarning=One or more plugins could not find the correct versions of the master files they depend on. Errors may occur during load or game play. Check the "Warnings.txt" file for more information.

[Archive]
sResourceArchiveList=Skyrim - Misc.bsa, Skyrim - Shaders.bsa, Skyrim - Textures.bsa, Skyrim - Interface.bsa, Skyrim - Animations.bsa, Skyrim - Meshes.bsa, Skyrim - Sounds.bsa
sResourceArchiveList2=Skyrim - Voices.bsa, Skyrim - Voicesixtra.bsa

[Combat]
fMagnetismStrafeHeadingMult=0.0
fMagnetismLookingMult=0.0

[Controls]
fMouseHeadingYScale=0.0200
fMouseHeadingXScale=0.0200

[Papyrus]
fPostLoadUpdateTimeMS=500.0
bEnableLogging=1
bEnableTrace=0
bLoadDebugInformation=0


[Water]
bReflectLODObjects=1
bReflectLODLand=1
bReflectSky=1
bReflectLODTrees=1

After lots of testing i'm starting to think the max stable uGrids setting is determined by the amount of video card memory you have.

The game isn't using as much system RAM as i expected so i don't think that is an issue, and other things such as CPU speed, GPU speed and hard drive speed are more likely to cause stutters and slowdown rather than crashes (if they are not fast enough).

Video card memory is the only thing this game seems to be maxing out a lot, and the extra textures needed for higher uGrids settings would be a good reason why the game crashes when you simply don't have enough.

That's not an excuse for Bethesda though.

yeah i would agree


considering the 512mb card I've got in one of my machines.. pushing ugrids to 7 results in frequent crashes...

the 1gb card runs 7 flawlessly, but pushing it to 9 results in occasional crashes and with ugrids set to 11 it's guaranteed frequently..

the 2gb card I've got run 9 flawlessly, but pushing it to 11 results in occasional CTD.... more often then i would like....

Someone i was talking to with a 3gb Nvidia card was running ugrids 11.... and pushing it to 13 resulted in crashes..

although later he admitted that 11 was just "to much of a FPS loss" and dropped down to 9...

So it does appear from initial reports.. that the higher the value.. the more vram your really going to need.. and it makes sense...

Oh I really wish they optimized the game for ugrids above 5.....

Maybe with this mod:

http://www.skyrimnexus.com/downloads/file.php?id=2006

We can test to find out the minimum required memory for uGridsToLoad=7, 9, and 11.

No, I've tested this and as you can see with Pala's results as well, upping uGrids doesn't add much to VMEM at all -- and that makes sense, the extra grids you're loading are most of the time containing the same models and textures as the ones already loaded (think trees, rocks etc), the game is simply rendering more of them further.

But yes, there is a bottleneck. i7 980X with 6GB RAM, GTX 580 SLI and when I use uGrids 7, 9 or 11 I get the same results as Pala -- FPS drops through the floor the higher you go but none of CPU, MEM, GPU or VMEM are maxed. There's headroom in the machine, but it's not being used.


EDIT: Tools I used which may help others:

Nvidia Inspector to measure GPU load and VMEM load -- http://downloads.guru3d.com/NVIDIA-Inspector-1.94-download-2612.html
Process Monitor to measure CPU load, System MEM load and CPU cores being used -- http://www.techpowerup.com/forums/showthread.php?p=1732756

Very good thread this one, and yes ive to agree with the above post. I use ugrid 7 and I get a massive fps drop but the game doesnt utilize my gpus to the maximum. It stays at 50-60 % while other games it easily reaches 90-98 %. So Bleh-thesda has to work better on how to use the hardware better of computers instead of focusing on consoles only, that is if they want to learn how their own code rly works. Seems after oblivion they r still learning from it..