CPU usage in native Status Line always displays 0% unless using Fastest Possible

[giantclambake]

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

[midwan]

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.

[giantclambake]

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 =)

[giantclambake]

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

[giantclambake]

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

[midwan]

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?

[giantclambake]

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 ;)

amiberry.conf.gz

[giantclambake]

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

[giantclambake]

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.

[giantclambake]

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.

wb13.uae.gz

[giantclambake]

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

[midwan]

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). :)

[giantclambake]

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 ;)

[giantclambake]

Been meaning to retest this after 6months of improvements to amiberry .... not to mention having better monitor ;)

Just discovered this works caveat being able to make use of GUI ->Display-> Vsync Native

//system default = 60Hz v_refresh

Launch ./amiberry AmigaTestKit.adf ..once booted, F12 -> Quickstart -> check NTSC ; Display-> Vsync Native -> select Standard 50/60Hz ; Miscellaneous -> check Status Line native ---> hit F12 to resume

Result: Status Line native works correctly...I leave the emulation running on the Amiga Test Kit menu..

//I can do this on the fly with XFCE4 ...Settings -> Display -> Set v_refresh to 50Hz -> Apply

...return to emulation window -- CPU load in Status Line now not working and displaying 0%

F12 -> Quickstart -> uncheck NTSC ---> hit F12 to resume

Result: Status Line native works correctly.

The CPU->Fastest possible option is not required in the above cases.

So... Status Line native works, if NTSC/PAL v_refresh rates are synced with the host display v_refresh.

Makes me wonder why Status Line RTG works without this requirement ...

[giantclambake]

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). :)

FWIW, Toni briefly touched on this in EAB a few days ago...to wit... "It is basically: "time it took to emulate the frame" / "expected real world frame time" * 100.0% ("real world frame time" is normally ~20ms if PAL, ~16ms if NTSC) with some averaging to keep it less jumpy. The faster the emulated frame was completed, the lower the value. It is whole emulated frame, it includes everything needed to emulate it (CPU, chipset, rendering etc) "