04-19-2021, 09:31 PM
Hi, I am guessing approximately what "driver wake-up delay" setting does and I know of its effect. It certainly help in many games with stability, just experienced such improvement myself with Soul Calibur 5. It seems to me to have a similar function to what native Windows GPU drivers do: provide certain time window until which GPU must respond back or else its considered stall/locked/frozen. (Actual GPU driver would then restart itself on time expiry.) Only here it is for SPU's.
What I would like to know, from more technical point is the claim that "too high value can cause slowdown". To me it doesn't seems right because, for example if I set it to 4ms(4000us), I believe it is only supposed to set a time limit window to wait for an SPU core. This does not mean SPU core HAVE to take 4ms, it can finish much sooner and system can then move on right? I mean its not a constant time scheduler of 4ms loop right?
Then if above is correct, setting much higher value should only improve stability at no cost, after all once the time window is "not enough" and run out, SPU thread will desync causing whole emulation to lock or freeze. So it does need whatever time it need anyway to *not crash*, it is then up to performance of the underlying host how fast it can pull off the work. If its too slow nothing that can be done but its better to wait than to crash, if its fast enough there shouldn't be too long waiting times in the first place.
Is my assumption correct or does it work differently and if not, why not just make a default of say 2-6ms(2000-6000us)? As it would increase stability and compatibility of many games especially on lower end systems and decrease overhead of false bug reports etc..
What I would like to know, from more technical point is the claim that "too high value can cause slowdown". To me it doesn't seems right because, for example if I set it to 4ms(4000us), I believe it is only supposed to set a time limit window to wait for an SPU core. This does not mean SPU core HAVE to take 4ms, it can finish much sooner and system can then move on right? I mean its not a constant time scheduler of 4ms loop right?
Then if above is correct, setting much higher value should only improve stability at no cost, after all once the time window is "not enough" and run out, SPU thread will desync causing whole emulation to lock or freeze. So it does need whatever time it need anyway to *not crash*, it is then up to performance of the underlying host how fast it can pull off the work. If its too slow nothing that can be done but its better to wait than to crash, if its fast enough there shouldn't be too long waiting times in the first place.
Is my assumption correct or does it work differently and if not, why not just make a default of say 2-6ms(2000-6000us)? As it would increase stability and compatibility of many games especially on lower end systems and decrease overhead of false bug reports etc..