You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Would it be possible to introduce a "Throttle CPU speed" option for the approx/cycle-exact mode?
The use-case is watching 040/060 demos where you need to fine-tune the actual speed with the slider to approximate a "good semi-realistic" framerate.
As an example, Little Nell by TBL runs fine with "fastest possible", but I'm really uncomfortable using that as the results are very much host CPU dependent. E.g., your config can break in the future with your next CPU upgrade... who knows. We face that problem a lot in DOSBox Staging when people use cpu_cycles = max. It's a time-bomb...
Then if I set x16 and 150% with Little Nell, the speed seems about right, but in many parts the audio emulation can't keep up so I'll get massive buffer underruns that never recover... (Yeah, and we have the same problems with audio and cpu_cycles = max in DOSBox land...)
Our solution is to enable CPU throttling in addition to specifying the desired CPU speed, which then acts as an "upper limit" for the thottling, effectively.. In WinUAE's case, the final speed resulting from the CPU Frequency multiplier and the percentage slider would be best-effort; only if the host CPU can keep up. If not, it would be throttled, just like in "fastest possible" mode. The end result is that we'd never go above our speed target so there's never a risk of going "too fast" on really fast host CPUs, but buffer underruns would be 100% mitigated because of the throttling.
Also, in some demos the "fastest possible" mode just regularly starves the audio emulation and you get stutters, no matter what (e.g. J by Ephidrena, from memory). An upper limit for "fastest possible" would fix these up as well.
Mockup for the new checkbox:
The text was updated successfully, but these errors were encountered:
I would just say getting accurate/approximate speed to a real 060 is very difficult because even if you manage to tweak one demo to match the original hw somewhat it may not work as good for the next demo. It all comes down how to the code was written (in terms of pipe-lining, cache usage, writes to chipmem, etc)
I would just say getting accurate/approximate speed to a real 060 is very difficult because even if you manage to tweak one demo to match the original hw somewhat it may not work as good for the next demo. It all comes down how to the code was written (in terms of pipe-lining, cache usage, writes to chipmem, etc)
I fully understand that. Hence I'm saying, I just wanna tweak it via the relative speed percentage slider to taste (yes, per demo, absolutely; I'm using separate configs per demo), and I get it the mix of CPU instructions, caching, pipelining can vary from part to part even in the same demo. But it's better than nothing or just "go at full host CPU speed". Just without throttling you invariably get buffer underruns if your host CPU can't keep up.
Would it be possible to introduce a "Throttle CPU speed" option for the approx/cycle-exact mode?
The use-case is watching 040/060 demos where you need to fine-tune the actual speed with the slider to approximate a "good semi-realistic" framerate.
As an example, Little Nell by TBL runs fine with "fastest possible", but I'm really uncomfortable using that as the results are very much host CPU dependent. E.g., your config can break in the future with your next CPU upgrade... who knows. We face that problem a lot in DOSBox Staging when people use
cpu_cycles = max
. It's a time-bomb...Then if I set
x16
and150%
with Little Nell, the speed seems about right, but in many parts the audio emulation can't keep up so I'll get massive buffer underruns that never recover... (Yeah, and we have the same problems with audio andcpu_cycles = max
in DOSBox land...)Our solution is to enable CPU throttling in addition to specifying the desired CPU speed, which then acts as an "upper limit" for the thottling, effectively.. In WinUAE's case, the final speed resulting from the CPU Frequency multiplier and the percentage slider would be best-effort; only if the host CPU can keep up. If not, it would be throttled, just like in "fastest possible" mode. The end result is that we'd never go above our speed target so there's never a risk of going "too fast" on really fast host CPUs, but buffer underruns would be 100% mitigated because of the throttling.
Also, in some demos the "fastest possible" mode just regularly starves the audio emulation and you get stutters, no matter what (e.g. J by Ephidrena, from memory). An upper limit for "fastest possible" would fix these up as well.
Mockup for the new checkbox:
The text was updated successfully, but these errors were encountered: