Hi Boris,
I have been using ENB for Skyrim Special Edition and I'm very pleased with it, performance is great and visuals as well, so thanks a lot for all your work.
One of the problems ENB has still is the much increased loading times due to recompiling shaders.
Since I'm one of the Mod Organizer 2 developers I have had the opportunity to gather information from a lot of different users reporting their experience and I can see that a lot of people experience various degrees of substantial increase.
I wanted to ask if it was somehow possible to introducing a "run once" step plus caching of the results, to cut down of the load times.
I'm no graphic developer so I wouldn't know if this is possible, just coming from an outside point of view I was curious if something that needs to be done at each startup could instead be done only once, at least until the user doesn't want to change something in his setup.
I would expect something like this would deny the ability to change settings on the fly or at least be needed whenever the user wants to change his shaders and effects.
After tweaking ENB until the he is satisfied, the user will usually very rarely need to change it again so after that I would see a lot of users caching their current configuration in exchange for faster load times.
I say this because, like many other modders I spend more time testing mods than actually playing the game, so opening and closing the game happens thousands of times and any performance improvement there would be very welcome.
Again I don't know much about graphics programming so I don't know if what I'm proposing makes any sense.
Reducing startup time
- Author
- Message
-
Offline
- *blah-blah-blah maniac*
- Posts: 17559
- Joined: 27 Dec 2011, 08:53
- Location: Rather not to say
Re: Reducing startup time
Hi. Of course i know this, i hate myself to wait, must restart game for testing countless times. But the part which actually patching shaders tooks just 8 seconds as i remember, everything else is what driver do to shaders (some optimization too). So even if i generate all shaders from preset and dump them to files for reading faster next time, driver will be stuck anyway and the only "enable shader cache" in driver control panel help to decrease loading times a lot. Patched shaders are considered as unknown, so driver process them all and game have very huge amount of shaders, so the time is x4-x8 longer than old skyrim without shader cache as driver feature. It's out of my control.
_________________
i9-9900k, 64Gb RAM, RTX 3060 12Gb, Win7
i9-9900k, 64Gb RAM, RTX 3060 12Gb, Win7
-
Offline
- Posts: 17
- Joined: 18 Jul 2018, 15:35
Re: Reducing startup time
While testing if there was difference when using the shader cache or not we noticed that if the shader cache is enabled in the driver settings then the game is loading completely single core, while normally, without ENB or even with ENB + shader cache disabled the game uses 100% CPU.
Is ENB using some kind of critical section there? Can it be avoided?
Is ENB using some kind of critical section there? Can it be avoided?
-
Offline
- *blah-blah-blah maniac*
- Posts: 17559
- Joined: 27 Dec 2011, 08:53
- Location: Rather not to say
Re: Reducing startup time
I compile mod shaders in multiple threads at the beginning, but game shaders are patched and created in single thread. Nvidia driver disable shader cache if detecting creation of shaders from several threads and this increase time a lot.
_________________
i9-9900k, 64Gb RAM, RTX 3060 12Gb, Win7
i9-9900k, 64Gb RAM, RTX 3060 12Gb, Win7
-
Offline
- Posts: 17
- Joined: 18 Jul 2018, 15:35
Re: Reducing startup time
The fact that everything is slowed down to single thread is having very bad repercussions for loading times for a lot of users, especially those with low single core performance.
I tried finding more info about the drivers not using the cache if there was multithreaded patching or if patching was detected, but could not find anything relevant (I imagine this might not be something too common so I'm not too surprised). Can you give me some more info?
From what I understood the patching would happen before the data can get to the driver and the driver should not be able to tell that the shader has been patched. It should, from what I could understand, handle it like any other shader and use the cache if it is available for it.
Could you tell me more about this problem with the drivers? Because CreateVertexShader/CreatePixelShader in the patching process should be designed to be used with multithreading and the fact that there is a critical section is so damaging to the performance that I don't even know if the cache would be worth the trade off.
If you can get me some details on this, even technical, I would be very grateful. I can search things up later if there is something I don't understand.
I tried finding more info about the drivers not using the cache if there was multithreaded patching or if patching was detected, but could not find anything relevant (I imagine this might not be something too common so I'm not too surprised). Can you give me some more info?
From what I understood the patching would happen before the data can get to the driver and the driver should not be able to tell that the shader has been patched. It should, from what I could understand, handle it like any other shader and use the cache if it is available for it.
Could you tell me more about this problem with the drivers? Because CreateVertexShader/CreatePixelShader in the patching process should be designed to be used with multithreading and the fact that there is a critical section is so damaging to the performance that I don't even know if the cache would be worth the trade off.
If you can get me some details on this, even technical, I would be very grateful. I can search things up later if there is something I don't understand.
-
Offline
- *blah-blah-blah maniac*
- Posts: 17559
- Joined: 27 Dec 2011, 08:53
- Location: Rather not to say
Re: Reducing startup time
I have found only one post on nividia developers forum where guy reply himself that time of shaders creation greatly increases if they are created from threads over than primary. Driver seems detect this condition and switch to some slow procedure without caching maybe. But i also suspect when in single thread mode, driver put shaders to processing for much longer time till they will be used by the game, this explains why after loading game scene, fps is low for several seconds, but when i did multithreaded version at first, it was high from the start. Just forget it, there is nothing to do about this problem.
_________________
i9-9900k, 64Gb RAM, RTX 3060 12Gb, Win7
i9-9900k, 64Gb RAM, RTX 3060 12Gb, Win7
-
Offline
- Posts: 17
- Joined: 18 Jul 2018, 15:35
Re: Reducing startup time
Another dev directed me to this: https://www.slideshare.net/mistercteam/ ... cereloaded , with the first 6 pages containing comments relevant to this.
I was advised to add a cache for the patching stage, since the game has a very high amount of shaders (16k afaik) and the program (ENB) has to patch them all, this way there would be no need to multithread on the ENB code and NVidia can use it's cache correctly without issues because of it.
Would such a solution work?
I was advised to add a cache for the patching stage, since the game has a very high amount of shaders (16k afaik) and the program (ENB) has to patch them all, this way there would be no need to multithread on the ENB code and NVidia can use it's cache correctly without issues because of it.
Would such a solution work?
-
Offline
- *blah-blah-blah maniac*
- Posts: 17559
- Joined: 27 Dec 2011, 08:53
- Location: Rather not to say
Re: Reducing startup time
Listen, i had multhithreading creation of shaders before and people reported huge degradation of startup time. I deleted it after finding out its nvidia driver turn of it's own optimisation when detects multithreading. What do you want from me? Restore back code which do not work, just because of some papers? No way.
_________________
i9-9900k, 64Gb RAM, RTX 3060 12Gb, Win7
i9-9900k, 64Gb RAM, RTX 3060 12Gb, Win7
-
Offline
- Posts: 17
- Joined: 18 Jul 2018, 15:35
Re: Reducing startup time
No, I was proposing the opposite: not use multithreading when patching, but to save for the lost time add a cache for the patched shaders (HLSL Bytecode), so you can use that instead of having to patch the 16k shaders in single thread. Since you don't use any multithreadting Nvidia shouldn't act up and should use his own cache for final step.
Does that make some sense to you? Basically we go back to what I was originally proposing which was to avoid having to do the same thing all the times you start the game. If we can't use multithreading to go faster because of Nvidia not liking it, we can try to avoid doing the single threaded part altogether by using previous results of the patching process.
I might be missing some important points here, in that case please let me know.
Does that make some sense to you? Basically we go back to what I was originally proposing which was to avoid having to do the same thing all the times you start the game. If we can't use multithreading to go faster because of Nvidia not liking it, we can try to avoid doing the single threaded part altogether by using previous results of the patching process.
I might be missing some important points here, in that case please let me know.
-
Offline
- *blah-blah-blah maniac*
- Posts: 17559
- Joined: 27 Dec 2011, 08:53
- Location: Rather not to say
Re: Reducing startup time
I already said that patching shaders takes 8 seconds and i am not interested to write complicated code to short this time in 2-4 times. Everything else is on nvidia side, driver do spent huge time with compiled bytecode, not the mod.
_________________
i9-9900k, 64Gb RAM, RTX 3060 12Gb, Win7
i9-9900k, 64Gb RAM, RTX 3060 12Gb, Win7