amiberry
amiberry copied to clipboard
BlitterStudio
CPU usage in native Status Line always displays 0% unless using Fastest Possible
git-master/x86-64/linux
To recreate;
Create a simple A500 .uae config, loading kickstart 1.3 with workbench 1.3 floppy image in DF0: and ensure GUI->Miscellaneous->Status Line native is enabled ; start emulation, observing Status Line CPU % value.
On the hardware I'm using, I may initially and briefly see the CPU % value hit 3~5%, but on the linux host side using top, the amiberry process is utilizing 25% of CPU load on avg. Thinking this might be due to the process thread being spread over 4 cores, I used taskset to force the amiberry process to a cpu_affinity of 1 core, but it made no difference to the Status Line.
Note: using the status line in RTG mode with a typical ClassicWB setup in emulation, does report the host CPU load correctly.
I am supposing the expected behavior here, is that the CPU % indicator accurately reports host CPU load, regardless of what's being emulated or which display mode is selected for the Status Line?
TIA
I cannot recreate this, at least when testing on my Pi400 running Manjaro. Using the same steps as described above, I see the CPU usage fluctuate between 0-20% while waiting in the Kickstart 1.3 screen.
OK, it may be x86-64 related ~ now that I have both rpi3/rpi4 platforms, I'll retest this and see if I can get a better angle at the problem.... thanks =)
M'kay ... given your result, I decided to tangent off x86-64, and redo the test on the rpi4-B-4g (closer machine target)
This is HDMI capture @ 1280x720, running 2023-10-10-raspios-bookworm-arm64-full.img ... allegedly a picture paints a thousand words, and to see is to understand (I hadn't tried this on other hw ;)
https://www.youtube.com/watch?v=WKRXYL_L9nA
On the m93p thinkcentre, deb 12.1, same test and more or less same result,...you see what I mean -- CPU utilization remains at 0% ...same here on this amd64 box with x86-64 amiberry build.
https://www.youtube.com/watch?v=PqgmxHmQpME
I still cannot recreate this here, on the platforms I'm testing. Did you try just using Quickstart -> A500 (as it comes up by default really), then inserting Workbench 1.3 into DF0, enabling Status Line Native and Start?
That's what I did, and I'm seeing the CPU usage fluctuate as expected.
Can you attach your amiberry.conf file, to check for any default values that might be different from what I have?
Apols for belated reply here...
Quickstart -> A500 (as it comes up by default), then inserting Workbench 1.3 into DF0, enabling Status Line Native and Start?
Same result following this example ~ CPU utilization is always 0%
Requested file attached ;)
Finally found the trigger for this...
GUI->Quickstart->A500 .... if CPU Speed is set to 7/14/25Mhz (CPU and FPU panel), Status Line native does not work and always displays 0% CPU utilization...
If however CPU Speed is set to 'Fastest', Status Line native works as expected.
I get the same result with other selected Amiga models -- the CPU Speed has to be set to 'Fastest', for Status Line native to work.
x86-64 / debian bookworm / amiberry v5.6.4
HTH
Just noticed this works as expected in v6.1.2 preview.
Still does not work in v5.6.5 however, same behavior as per last post above.
This has actually gotten worse... v6.2.1 preview / x86-64
-sound utilization always at +50 even though floppy sounds not enabled -CPU utilization always 0% ~ using 'fastest possible' for CPU speed no longer seems to get it working.
Still seems to work in RTG mode however.
A bit better now, but still hinky ....CPU flicking to 137 coincidental with framerate dropping to 37fps (which I don't think is actually happening, framerate seems solid). Sound utilization seems better now. Still the case that 'Fastest possible' needs to be enabled .... at 'normal' emulation speed, host CPU hovers between 17%-25% utilization, but statusline displays 0% in this case. https://www.youtube.com/shorts/5RBCEFf3ktA
The code that calculates the FPS and CPU percentage, is identical to that of WinUAE. Indeed, I see the same numbers there as well. I'm not sure if this is a bug that Toni missed, or if it's designed to work this way (and we misunderstood the purpose). :)
Fortunately for me it's not a feature I rely on nor use typically, but I do obviously check it. If this is some kind of upstream bug in winuae, then there's likely aught that can be done about...
....good to know you're seeing the same thing however, and it's not just specific to my setup ;)