Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Throttle CPU speed option #316

Open
johnnovak opened this issue Jan 4, 2025 · 2 comments
Open

Throttle CPU speed option #316

johnnovak opened this issue Jan 4, 2025 · 2 comments

Comments

@johnnovak
Copy link

johnnovak commented Jan 4, 2025

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:

image

@emoon
Copy link
Contributor

emoon commented Jan 4, 2025

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)

@johnnovak
Copy link
Author

johnnovak commented Jan 4, 2025

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.

PS: Nice to see you here 😎

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants