Reducing startup time

[al12rs]

I will test later with the official files to exclude that this is due to mod shader compiling.
I will tell you though that a part from a initial spike of a second or so the rest of the loading is happening on a single core (corresponding to the "compiling shaders, enable shader cache for better performance" part), then there is a 5-6 seconds or so part of 80-90% CPU utilization while the Skyrim menu is loading with the small circle.

So in the 25+ seconds of single core what is happening again?

Another thing that came up while discussing with other developers was the ability of ReShade to recompile the shaders using constants instead of variables for improved performance of the final shader. That removes the ability to change values from the in-game menu but should give a performance boost.

Is the same logic applicable to ENB? Like edit the .fx files and replace the float/int that come from <string UIName="<stuff>", with constants, for example

Code: Select all

float Technicolor2_Red_Strength         < string UIName="Technicolor2_Red_Strength"; string UIWidget="Spinner";float UIMin=0.05;float UIMax=1.00;float UIStep=0.01; > = {0.30};
can be replaced with 
float Technicolor2_Red_Strength = 0.5

.

Do you expect this to have better performance?

[ENBSeries]

Performance of such changes will be very tiny in the most cases, unless very stupid code is used like using many constants inside long cycle. Btw, using reshade together with enbseries probably #1 culprit of slow performance, if reshade also do disassembling, assembing and creation of shaders.
At first, when game starts, mod creating resources (textures/render targets first of all), then huge cpu usage is compilation of mod shaders on several cores (dont remember, around 6-9 threads spawned). Then game creating shaders on single core for long time and they are patched by the mod (disassemble, process text, assemble, create modified shader). Then game do something i dont know and basically starts.

[al12rs]

I don't use ReShade since it had too much of an impact on performance.

For me the Mod shaders compilation takes only 2.226 seconds, or at least that is the amount of time that I see the multithreaded spike, I don't actually know if they are finished after that spike. After that short spike of CPU usage it stays at single core for about 22 seconds and in that period the debugger says the code is in d3d11.dll. In the end everything returns multithreaded for the last part where I couldn't see any activity from ENB, so as you said, the game does some stuff multithreaded and then it's done.
Here is a picture:


The 22 single core portion I get should be this: `Then game creating shaders on single core for long time and they are patched by the mod (disassemble, process text, assemble, create modified shader)`
Does 22 seconds sound right for this step or does that contain also other stuff?
And nothing in those 22 seconds can be made multithreaded? Disassembling? Assembling? processing text? compiling vanilla shaders?

Compiling shaders in the background and putting checks around is something I wouldn't like either so I agree with you there.

[ENBSeries]

Yes, 22 seconds must be all those procedures for game shaders. I have measured just pixel shaders 16 sec, so summary with other types they should give that number. The biggest time cost is to assemble them after patching, 8.5 seconds for pixel shaders. Dissasemble around 3.5 seconds. I cant touch dissasembly, cause its made using d3d library and nothing to optimize there. I tried optimize assembling code, but it's just heavily using stl with many vectors and strings work, it sucks by performance. Caching via files of course good way, but i still dont like it because any simplest changes about files will chance hash and require to be generated again and users are so lame that will share those files in presets. I thought to take a risk and process shaders in other threads without creating them, so on call set pixel shader i can check if modified not yet created, create it from generated data, but the problem is in making critical sections there to sync data from other threads, so the place to do that is not very nice by performance. Shaders must be created from main thread, but can be processed in others. Using multithreaded processing may be even better than caching files, cause 16 seconds for ps 1 thread is x4 times faster when using 4 threads (in ideal scenario of course), do not waste memory on hard drive, but risky. Anyway, i'm thinking on this problem whole day, will find out something perfect.

[al12rs]

That is good to hear.

You expressed concern for wasting disk space when caching files, I wouldn't have though of that as a factor, how much space are we talking about? Because I would expect most modders to not have to worry about disk space.

About the problem that people would share the cache files, if you store them in their own folder "/Skyrim Special Edition/EnbSeriesCache" for example that shouldn't be a problem. Some other developers proposed using other locations such as "Documents/MyGames" since apparently some games already use that folder for cache.

As for determining whether to use the cache or not you could just make it a simple toggle in the ini file. If it is on and there is a cache, you use the cache and ignore any setting by the user (put a warning at ENB startup message that user settings will be ignored until cache is disabled).
If the cache setting is enabled but there is no cache, use the current user settings to generate one.
If cache setting is disabled, delete cache if there is one and work as would now.

I would keep this solution in mind if you can't find a way to increase performance via multithreading.

Great job by the way for the 8 seconds reduction, it's not massive but still a pretty good decrease.

[ENBSeries]

Many users are dumb as hell, they share enblocal.ini, they write me bug reports about messages i show at startup. So i dont want to add any more headache to myself, i have a life to live, not to answer their same stupid questions here.

[al12rs]

I get where you are coming from, since I deal with Mod Organizer 2 issue reports all the time.
Still it would be really sad if the improvements are held back simply because people are deemed too stupid to handle it.

When working on Mo2 I decided that I would rather provide the features for the people that are intelligent enough to use them (or at least have the intelligence to follow guides without messing up), rather than limiting functionality for everybody.

Well you have surprised people time and time again, so I guess I will have to wait and see what you come up with.

Let me know if you make progress, I will gladly test and give you results from different setups as I have multiple people really interested in this as well.

[ENBSeries]

I'll just release new update without informing. Sorry, if i implement some idea, it's easier for me to not wait and just publish.

[al12rs]

All right, I will be on the lookout then.