61 replies to this topic

[EssArrBee]

On the ENB forums or the Nexus thread I guess. Also, you could just ask him and probably send him some Windows error reports when you get crashes at high ugrids and ILS.

[WilliamImm]

Man, if he can make ILSes go bye, I may seriously consider bringing back my current game.

[MontyMM]

To give everyone an idea of what they're up to, here is an exchange from Altimor and Boris that I clipped out of a long and sprawling thread on his forum.  Don't worry if you don't understand exactly what they're talking about, but after the scams and unpardonable bollocks of the previous memory and stabilty "apps", this is a refreshing example of what technical NON-******** looks like.  :P

Keep your fingers crossed that these guys keep working on this stuff, because they may be able to uncover and address many stabilty issues in this way.

A: "Turns out there's another bug w high ugrids, an infinite loop in cell loading code. I hope to fix it tomorrow. I'm working on multithreaded cell loading atm."

A: "It definitely seems to be very finicky regarding PC differences. I can get grids up to 13 (poor performance but stable), other people have been able to use 15. For some reason if it fails the grid loading thread just continues forever. Breaking with the Visual Studio debugger during such a freeze showed that most of the threads were waiting for the grid loading thread to finish."

A: "From what I can tell the infinite loading is caused by 2 threads waiting on each other."

A: "uGridsToLoad 21: https://i.imgur.com/qtJh1tg.jpg
     Extra contrast to show distant terrain: https://i.imgur.com/i8tLHNo.jpg

I have a rudimentary fix for the threading deadlock, but I'm not convinced it's stable right now."

B: "I hope you didn't changes to functions of critical sections or other similar as it's not solution, rather new bug. Please confirm or users will corrupt their saves."

B: "Hmm, just thought that replacing thread sync functions can be good idea, if to bypass only specific threads. Gonna try myself, but such simplest tricks require heavy testing."

A: "I stop a specific WaitForSingleObject several calls deep in CellRefLockEnter, I'm aware it's probably not safe and that's why I'm not releasing it yet."

B: "Then better to detect which threads to bypass after some time, from my experience render thread and objects loading thread may work together not synced without issues to files, some graphic bugs occur, but it's minor. The same should be with sound thread (that damn with real time priority)."

B: "Just thought, any changes to sync functions may fail in "non game" conditions, like alt+tab and some time passed after this. Don't forget to test also."

[Aiyen]

Ah Monty... Technical NON ******** might be a bit too much praise :P Half of it is russian, and the other half is... well russian with a dialect hehe! :)

[MontyMM]

Ah Monty... Technical NON ******** might be a bit too much praise :P
Half of it is russian, and the other half is... well russian with a dialect hehe! :)

Boris-English is far kinder to the language then the torturous contortions of logic and facts that it was subjected to by our native snake oilers! :P

[EssArrBee]

Here's where this plugin got started, basically saying that it's creating a stack within a stack within a stack wit... A: A recursive cell rendering function. Due to an unused logging function after the recursive call, the compiler used a CALL rather than a JMP- this caused a new call stack to be created, when rendering too many cells the game would eventually exceed the CPU's stack size limit.

[MontyMM]

Yes, and what I like about these core issues is that they could so obviously be responsible for fatal crashes, and he seems to think, perhaps possible to fix through DLL injection. What's really annoying, of course, is that the two main issues he's described, the infinite looping in the loading thread and the runaway unnecessary creation of new memory stacks, could have been fixed so easily by Beth coders.

[phazer11]

[quote='Aiyen' pid='49346' dateline='1378586412']Ah Monty... Technical NON ******** might be a bit too much praise :P
Half of it is russian, and the other half is... well russian with a dialect hehe! :)[/quote]
LOL, oh Aiyen you're so funny >V<
[quote='MontyMM' pid='49348' dateline='1378587206']
[quote='Aiyen' pid='49346' dateline='1378586412']Ah Monty... Technical NON ******** might be a bit too much praise :P
Half of it is russian, and the other half is... well russian with a dialect hehe! :)[/quote]
Boris-English is far kinder to the language then the torturous contortions of logic and facts that it was subjected to by our native snake oilers! :P[/quote]
Agreed
[quote name=''MontyMM' pid='49354' dateline='1378592785']Yes' date=' and what I like about these core issues is that they could so obviously be responsible for fatal crashes, and he seems to think, perhaps possible to fix through DLL injection. What's really annoying, of course, is that the two main issues he's described, the infinite looping in the loading thread and the runaway unnecessary creation of new memory stacks, could have been fixed so easily by Beth coders.[/quote']
Yes, regrettfully these days most companies don't test their own products at the least not as thoroughly or worse they simply don't care. Part of it I can understand I myself probably wouldn't want to work on the engine anymore after working on the game for five years (that's how long it took for them to build Skyrim from Oblivion right?)  My grandfather used to program for mainframes before he was able to sell his companies and patents to some bigwig (I can't remember which) and retire comfortably in his fifties. I wasn't even 7 and I could tell how much work he put into it (the passion you know?) 

[z929669]

Any updates on this? Why is it not being used in Skyrim LE? Who says that this is specific to increased uGrids?? It would seem that this kind of alteration would benefit standard uGrids by improving thread handling and CPU prioritization.

[EssArrBee]

That is my sentiment as well. uGrids affects saves in a negative way and this mod fixes that. I would not say this is core and probably put it next to something like Borderless Windows with a note that users that do not intend to change uGrids from the default have no real reason to use this, but everyone else this could benefit.

[rootsrat]

I think I recall Gopher mentioning that this actually does help even for default uGrids settings, but he based that statement on information he's read somewhere else I think. Sent from my GT-I9505 using Tapatalk

[z929669]

Updated OP with some data for this and the other stability mods.

[z929669]

I moved the posts referring to FPS, as I noticed that my original post on that topic should have been posted to the "Player Physics" thread, as that is the one Altimor recommended playing that mod at at least 60 FPS

[z929669]

No reason not to use this. Marking as 'accepted' for 2.2.8

[z929669]

Letting this one bake along with Safety Load. Should not be needed by STEP, but may be helpful. We can decide by consensus later.