Power management is way too aggressive regards gpu compositing of browsers and/or memory speed

[Jurek-Raben]

Testing with recent Firefox, Asahi's power management too drastically reduces the GPU's ability to do layer compositing. Once the power slider is set to the middle, the following demo already heavily starts to stutter. Even though what's live-calculated here is not really taxing for the tested M1Pro cpu/gpu.

Testing the same with Firefox macOS, you will see that it runs butter smooth, even 144Hz, even if the Firefox window is not focused. Same with Chrome. If you check the usage, this page even with the below mentioned webgpu background is taxing one core in sum around 100% with multiple Firefox processes.

I actually have no idea how the power management internally works, if it can be configured at such a fine-grained level. I guess not. Then I would assume that it's a problem how the graphics driver reacts to the lower power setting.

Anyway, here is the mentioned page. It's compositing multiple canvas layers. The background layer sometimes is a webgpu layer.

https://virtualcreations.de/error/

https://virtualcreations.de/error/?|trip <-- with webgpu background layer variant 1
https://virtualcreations.de/error/?|trip2 <-- with webgpu background layer variant 2

Goal would be a smooth browser experience as you get in macOS Firefox. You can see that the webgpu background actually renders smoothly, but the foreground stuff is skipping frames. The foreground stuff is using mostly cpu, a bit of gpu. I've already tried to optimize the processing.

btw. you might have to enable webgpu in Firefox "about:config" first. This is enabled by default in all major browsers now, but sadly only on macOS and Windows. But webgpu is rendering very smoothly in Asahi Firefox, too. So the problem is the compositing of the layers.

[chadmed]

The only thing we actively power-manage from userspace is audio with utilisation clamping for PipeWire, WirePlumber and speakersafetyd, so this has nothing to do with "Asahi" power management. Maybe the kernel's energy-aware scheduling is overzealous for bursty workloads, but that's sort of beyond our control.

Have you tried Chromium?

[Jurek-Raben]

Thanks for the insight. As you might guessed already, I have no clue about the systems in Linux :) Nor the details of the Apple hardware structure.

Yes, Chromium is better in compositing performance, not at all though like under macOS. But then webgpu only runs in software emulation in Chromium, for unknown reasons. I will write an enhancement request into Bugzilla.

Do you think it also could be related to the current asahi M-processor-gpu driver, not supporting specific functionality?

[Jurek-Raben]

Running firefox with this command quite fixes the problem (still some stuttering left, but way better), at "medum" power profile:
taskset -c 2-7 firefox

Stops firefox from using e-cores. So it seems to have to do with power management.

[Jurek-Raben]

Ah, I think I can stop searching, it's written right into the console when you run Firefox from there:

Crash Annotation GraphicsCriticalError: |[0][GFX1-]: EXT_semaphore_fd is not suppored (t=2.3027) [GFX1-]: EXT_semaphore_fd is not suppored

"EXT_semaphore_fd is not supported" indicates a failure in your system's graphics stack, specifically regarding how the browser or application communicates with your graphics driver to synchronize GPU tasks (using EXT_semaphore_fd).

This error is common on Linux, especially with Firefox or Chromium-based browsers, and often points to a conflict between the application's renderer (like WebRender or VA-API) and outdated/incompatible GPU drivers, or issues with Wayland/X11 surface importing.

So this needs to be implemented to make smooth sync work in the modern browsers.

[Jurek-Raben]

In about:support, this is under "WEBRENDER_COMPOSITOR" printed:

default	disabled	Disabled by default	Blockiert; Fehlercode FEATURE_FAILURE_DISABLED
user	force_enabled	Force enabled by pref	
env	blocklisted	Blocklisted by gfxInfo	Blockiert; Fehlercode FEATURE_FAILURE_WEBRENDER_COMPOSITOR_DISABLED

In macOS, there is a simple "default available".