Reduced performance compared to other compositors

[System64fumo]

This discussion will serve as a place to report/discuss performance degradation on specific hardware. (Usually ARM or some select Intel chips)

Known affected hardware

Broadcom SoCs (All BCM chips)
Amlogic SoCs (S905D3 as far as i'm aware)

How to benchmark/compare

1. Install glmark2
2. Run glmark2-wayland in Hyprland
3. Run glmark2-wayland in labwc or wayfire (As those compositors tend to have better performance)

Related

Batch rendering
Apple Sillicon

[gulafaran]

ive been trying to figure this out but its a bit hard.

the reason glmark2 is showing lower scores is because it calls wl_display.sync() after each commit, which itself is rather lol. and waits for the callback before proceeding to next. so it doesnt technically mean the rendering or commiting is slow, its something thats occuring in between thats holding up the sync callback, and as such glmark gets low scores.

[2636508.555] {mesa egl surface queue} wl_callback#24.done(2419)
[2636508.810] {mesa egl surface queue}  -> wl_surface#14.attach(wl_buffer#22, 0, 0)
[2636508.811] {mesa egl surface queue}  -> wl_surface#14.damage_buffer(0, 0, 2147483647, 2147483647)
[2636508.813] {mesa egl surface queue}  -> wl_surface#14.commit()
[2636508.813] {mesa egl surface queue}  -> wl_display#1.sync(new id wl_callback#24)
[2636508.816] {Default Queue}  -> wl_display#1.sync(new id wl_callback#31)

the wl_display.sync call is pretty much wait until previous commands are done and proceed again.
and thats why games in general isnt affected as much but this particular "benchmark" if you wanna call it that, is.

[gulafaran]

ive been trying to figure this out but its a bit hard.

the reason glmark2 is showing lower scores is because it calls wl_display.sync() after each commit, which itself is rather lol. and waits for the callback before proceeding to next. so it doesnt technically mean the rendering or commiting is slow, its something thats occuring in between thats holding up the sync callback, and as such glmark gets low scores.

[2636508.555] {mesa egl surface queue} wl_callback#24.done(2419)
[2636508.810] {mesa egl surface queue}  -> wl_surface#14.attach(wl_buffer#22, 0, 0)
[2636508.811] {mesa egl surface queue}  -> wl_surface#14.damage_buffer(0, 0, 2147483647, 2147483647)
[2636508.813] {mesa egl surface queue}  -> wl_surface#14.commit()
[2636508.813] {mesa egl surface queue}  -> wl_display#1.sync(new id wl_callback#24)
[2636508.816] {Default Queue}  -> wl_display#1.sync(new id wl_callback#31)

the wl_display.sync call is pretty much wait until previous commands are done and proceed again. and thats why games in general isnt affected as much but this particular "benchmark" if you wanna call it that, is.

what im trying to say here, the attach, damage, commit might be done in a matter of nanoseconds but the callback isnt recieved fast enough to keep up and as such its held back. can be anything from input processing to, some protocol stalling to something filling up the wayland event loop so the callback is late etc.

[System64fumo]

I see, But the thing is, glmark often provides a good metric for hyprland's responsiveness.
Back when hyprland had a major responsiveness issue glmark was able to detect that and after the issue was fixed the scores rose up significantly.

Not a perfect benchmark, But it's serviceable.
That being said i have a theory, Since i started to mess with opengl lately i think the issue is that Hyprland is just doing too much CPU->GPU stuff.
Cannot confirm yet, I will get back to you on that one in a few minutes.

[System64fumo]

Nope.., I gave batch rendering a shot but that didn't seem to do anything..

[gulafaran]

yeah ive digged tons of hours into this, im not sure what level of slowdowns that would be expected. since essentially the more surfaces the more things being drawn the more being done that callback might return slower. compared to niri/sway where we have all the blur and animations and things going around. i suspect there is more then one culprit behind this