Just wanted to report excellent crash free gaming with OSR 4.1 for the whole weekend so far!

bAllowDynamicResizing = 1

iHeapAlgorithm = 1

Looking to try out iHeapAlgorithm 5 next.


Thanks again Skyranger-1 :foodndrink:

I've been holding off on mentioning this for a while, because I've been playing very little, and my character only got involved in two relatively decent battles--but it at least appears that I've had success with heap mode 1, hash tables on, iHashtableResizeScale1 = 1, and iHashtableResizeScale2 = 3. No slowing despite having 7 participants in one battle, and about as many in the second. Each was indoors, however: the first in the sewers, the second in a cave. Running Marts and Frans.

The code is for 4.1.0. While the initial version of CallPerf predated 4.1.0 it was #ifdefed out for 4.1.0 as largely untested, incomplete, not needed by or ready for the larger audiences that tesnexus releases target. The current code is similar, but has more functions it watches, does a better job of handling recursive functions, and has been tweaked to add support function calls where the instruction includes a pointer at the function pointer instead of directly including the function pointer. It still can't hook calls where the function pointer is kept in a register... that may not be practical to do automated without interrupts, which would probably kill performance.

The code marked as "culling?" or something like that may not strictly correspond to culling. The only actual culling identified is very fast (about 1% of CPU usage in my test case), it's just that I think almost the entire rendering process ends up getting managed by the culling algorithm. The slow part in my test cases appears to correspond to something named BSShaderAccumulator, specifically where it's used by ShadowSceneNode (which ends up acting as sort of a root node for the whole scene). There are 4 other calls to the same function per frame, but only the one from ShadowSceneNode is slow. Exactly what BSShaderAccumulator is doing with all that time is not clear, but I think Scanti or someone said that its baseclass NiAlphaAccumulator is responsible for keeping a queue of transparent objects to sort and render, so it may be doing something similar for shaders or something. Its placement in the code is consistent with it flushing a buffer filled up by each individual element in the scene graph.

Hey, does anyone see stutter on approaching spawn points? And if so, what overhauls (including MMM) are you using? Some guy a while ago on another forum said:


It just occurred to me that that could conceivably be related to leveled list scalability, if so it ought to be fixable.

Yeah, I've always had that. It stutters briefly, which means I know there will be enemies rather close by. This with OOO/MMM/FCOM (can't really remember how it was with vanilla). It's the same with Oblivion and Fallout 3 (which I've played without any spawn adding mods, so I guess it goes for vanilla as well).

Have been testing with the Hashtaberesizing.
For me, Heapmode 5 did this one in.
When doing nothing, standing in town. My FPS spazed from my 32 to cap to zero, it was awfully weird.

With Heapmode 1 and HashtableResizing1= 2 , HashtableResizing2= 3, this effect was reduced.
Will now check what disabling Streamline will do.

I don't see it myself, but I mostly only use OOO, no MMM, no FCOM.

Oblivion leveled lists scale poorly (I haven't looked at the code, but the datastructure is such that it pretty much requires walking the list more than once). The operations that Oblivion performs on them are so trivial that that ought to be irrelevant for all but the most obscenely large leveled lists, but conceivably a full FCOM install produces leveled lists far larger than I would expect, or leveled list performance is far worse than I would expect.

Wondering if you still http://www.gamesas.com/bgsforums/index.php?s=&showtopic=1074452&view=findpost&p=15634776.

Um... I should have followed up on that more.

If I can get an efficient way of finding the maximum depth in the entire screen, I'll stick in an experimental culling modification. If I can get an efficient way of finding the maximum depth of each quarter (the upper left, upper right, lower left, lower right) or 16th of the screen separately then I might be able to be more aggressive there... would incur quite a bit more overhead doing things at a higher resolution, but could possibly produce better culling. Maybe.

But, the basic approach I'd be using for that would probably be of only marginal utility, only worth trying out because I think I already have everything else I need for the hook and the code should (cross fingers) be fairly simple. The getting of the max depth would have to be low overhead or it would undo the small benefits that this might provide. And I have sneaking suspicion that scanning the entire Z buffer from C code is likely to not be very efficient, especially if either the Z buffer has to be accessed across the PCI-e bus or copied across it.

Hey,

I have been trying to find a good configuration for your great mod here, and was also wondering about some of the settings involving multi threading in the oblivion.ini and if it is recommended to use them with OSR or not.

I have just installed OSR on my new install and am going to test it out some with default settings so I can see the difference once I turn on heap replacement. I have a couple questions if you don't mind, i'll number them to make it easier.

1. In order to get the maximum benefit out of OSR (and as I understand it, turning on heap replacement benefits multi-threading systems more so than non,) should the well-known multi-threading tweaks be enabled in the oblivion.ini. Such as the bBackgroundLoadLipFiles, FaceGen etc. and the iThreads/OpenMP tweaks that supposedly benefit multi-threading systems, or would OSR work better without them?

2. Of course it is different for everyone's computer and current setup, but in general, what would you recommend tweaking in the OSR.ini for a multi-threading system? I have read that enabling the heap replacement has benefited many. Should it be left on the default iHeapAlgorithm of 5 after enabling heap replacement?

Knowing this would greatly help me out. Thank in advance!

-J

1. That would probably maximum the performance difference between using OSR and not using OSR, assuming the same Oblivion.ini settings either way. But it would not necessarily maximize overall performance.
In other words, I do not know.

2. My recommendations are fairly simple:
2a. Enable heap replacement, use heap algorithms 1, 3, or 5, whichever is stable for you.
2b. Enable dynamic hashtable resizing.

You can measure the performance of the different heap algorithms (using bEnableProfiling) to pick the best for you, but I do not recommend this - the performance differences are generally small, the stability differences are sometimes very large. Likewise you can suppress additional critical sections to further reduce stutter, but it's not recommended.

That's great, thanks a lot. I guess i'll just have to experiment a bit with the Oblivion.ini settings. I am playing just fine without them tweaked right now and the default OSR settings. I will turn on heap replacement after a few to see the difference. I know it made a difference in my other setup.

Thanks for the great mod, so glad I came across this it has made a huge difference, and thanks for the quick response!

Post back if you notice any difference with the multithreading variables in the ini. I've read mixed results, leaning towards decreased performance, or no help at all, at the least.

I mentioned the multi-threading tweaks to IanPatt a while ago and he had this to say about them:


I have had another person suggest that these two lines be added to the Oblivion INI file in the [General] section:
bUseThreadedAI=1 Might allocate AI to multiple threads. Choose 1 or 0.
iNumHWThreads=2 Might limit cores used to that number. Use any positive integer.

BTW Sky Ranger, how exactly would you install this in Fallout 3? I tried putting OSR's files into the Data/FOSE/Plugins folder. The first time, it complained that FastMM4's files weren't present so I installed them according to how they are installed in Oblivion's folder. This time there are no error messages but no INI file is created no matter how many times I run FO3 with FOSE.

While FSR is produced from the same source code as OSR, it's a different dll. Technically I could probably make one dll that could act as both, but I'd have to some funky stuff with the preprocessor and I'm just not set up that way atm.
FSR forum thread: http://www.gamesas.com/bgsforums/index.php?showtopic=1069833
FSR nexus page: http://www.fallout3nexus.com/downloads/file.php?id=8886

Where did you see these and can you tell if they made a difference? Especially the AI one.

There do not appear to be any such settings in Oblivion 1.2.416.

The only settings (based upon the names) that I would add to those listed in the IanPatt quote are
bUseBackgroundFileLoader and bUseBackgroundPathing.

Right, that's why the guy was saying to add them, but I was more curious about where the info came from than if it was valid or not.

Do bUseBackgroundFileLoader and bUseBackgroundPathing actually do something in the code?

I believe those are recommended teaks to add to the FO3 ini... maybe it would work with OB too. :shrug:

I have set bUseBackgroundFileLoader=1, though a lot say it doesnt help, but it seems to put the terrain loader stuff in the background,
therefore the "Loading Terrain" message appears to be a lot shorter.

regarding stability i cant really say if its worse cuz i have CTDs randomly on 1 to 30 min basis.


my values regarding multithreading are:

iThreads=20 // thread pool

iOpenMPLevel=10 // this determines the priority the threads are set to
an abstract value, because of the multi platform ability gamebryo has, 10 defaults to above normal on windows and shouldnt be changed,
if set higher the threads are assigned to a higer priority, but this can mix up interaction, and lead to less desirable effects

not part of the subject:
as I remember windows got 32 priority stages, and it was part of dicussion to be changed for win 7 to a higher value as 128 (linux does have already 128 or 256 for better granularity)
more common on windows are the above_normal, blow_normal assignments, which correlate to a certain priority level of the 32 windows does use.
conclusion if you set openMPlevel=15 you really dont know exactly what priority the threads get. anyway above_normal (OpnenMPLevel=10) is already prioritised,
and should assign most system ressources to the oblivion process.

I guess as long as it doesn't destabalize something it may be worth it. But a lot of these settings seem to be more placebo than real and you often can't tell any difference.



IanPatt already said that even though the game executable READS the values, it does nothing with them at all. So you're shooting blanks there. Fiddling with it will do absolutely nothing, and you can verify that easily enough by setting insanely high numbers and watch as nothing different happens in game.

In that case I have to chuckle at that very long thread last year saying that setting iThreads to 1 made the game feel smoother.

I remember that. was it really all just placebo?

Not really, as I set iOpenMPLevel=32, i noticed different stuttering,
really noticeable, that might happened due other threads/processes important for providing data being disrupted.

I dont think that my impression was just too subjective, but I didnt test it a second time.

OSR 4.1:
I have dynamicresizing and heap(1) active, and it doesnt seem to cause CTDs beside the ones already there.
One feature causing loads of CTDs, is the timekeepers feature to do pcb's every cell( every ext. cell counts)
switching this back to only interior/exterior and using the heap(1) seems to improve a lot.
(is the interior/exterior cell buffer handled in the heap?)

even setting bSaveOnInteriorExteriorSwitch=0, helped preventing some of the interior/exterior switch crashes.
they occur much less now.

but to say, lots of CTD happen after exterior cell switches( timekeeper makes this visible using the "show time"-option for every cell change(with cell changes set to every exterior cell))

PS:
I am using Win7/64 Bit on e8400/3.5ghz

Maybe someone should open a thread like ".INI settings that really, 100%, totally not subjectively affect something in-game!" :ahhh: