16:32 <enunes> linkmauve: I think even if you managed to compile that shader it wouldn't be very performant on the mali400, seems like it badly needs some optimization in glsl

16:33 <enunes> linkmauve: still, I did some gtk builds some weeks ago, what would I need to do to reproduce this runtime crash that you get? just build master?

16:34 <enunes> one thing I found out some time ago was that using RGB format instead of RGBA triggers the texture swizzling path since it forces the value "1" in the alpha channel

16:34 <enunes> so since you cant reproduce it with shader-db, maybe its just some difference like that at runtime

16:34 <linkmauve> enunes, they did some coarse profiling of how many pixels are drawn with each shader (not accounting stuff like scissors), it’s over there at the top with zero pixels drawn using it: https://paste.centos.org/view/436726db

16:35 <linkmauve> enunes, yes, just build master.

16:35 <linkmauve> Although the NO_CLIP variant of that shader is newer than GTK master from a few weeks ago.

16:35 <enunes> and then just run gtk4-demo with GLES2? some specific command that you are using?

16:36 <linkmauve> Yes.

16:37 <linkmauve> GDK_DEBUG=gl-gles GSK_RENDERER=ngl GTK_INSPECTOR_DISPLAY=$WAYLAND_DISPLAY GTK_DEBUG=interactive WAYLAND_DISPLAY=wayland-0 are the environment variables I use to get the inspector to run over waypipe, assuming your board’s compositor is running at wayland-0.

16:38 <enunes> but which gtk4-demo scene, gears, gltransition, doesnt matter?

16:40 <linkmauve> The main one is fine, --run=gears gives you a framerate counter out of the box so I often use that.

16:40 <linkmauve> So far I’ve been mostly profiling scrolling in the main view.

16:41 <linkmauve> On the ngl-tweaks branch from this morning, scrolling there with Lima reaches 36 fps!

16:41 <linkmauve> Although there is a super weird regression where it drops down to 22 fps unless GSK_DEBUG=full-redraw is passed.

16:42 <linkmauve> They merged that optimisation yesterday, which mostly just redraws less and uses eglSwapBuffersWithDamage() to give only the changed regions to the compositor.

16:42 <enunes> full redraw sometimes is better on tiling gpu, dont know if you came across https://community.arm.com/developer/tools-software/graphics/b/blog/posts/mali-performance-3-is-egl_5f00_buffer_5f00_preserved-a-good-thing

19:37 <anarsoul|2> linkmauve: yeah, for tiling GPU it's important to scissor the area that you don't touch (even if it won't be overwritten by draw)

19:43 <enunes> linkmauve: ok I can reproduce it, lets see now...

20:38 <enunes> apparently we should move our last nir dce to a bit later

20:38 <enunes> linkmauve: with some fix gtk4-demo gears runs at 40dps to me

20:39 <linkmauve> Getting 32~34 fps atm there, with GSK_DEBUG=full-redraw.

20:40 <linkmauve> Oh, or 37 fps without it this time!

20:40 <linkmauve> I guess that’s because it does the glClear() up-front, in a large area?

20:41 <enunes> it might be that it does so and so a followup draw doesnt have to reload the last framebuffer, which is an expensive operation

20:45 <enunes> for me though GSK_DEBUG=full-redraw drops -10fps

20:47 <linkmauve> Looking at their rendering process, they first clear then draw the gears into a texture using a fbo, then clear with a scissor and then draw that texture (and then the framerate counter).

20:48 <linkmauve> And the gears occupy the most space on screen.

21:05 <enunes> hmm yeah that shader has things like r8 = vec3 ssa_1.x, ssa_3, ssa_551 where ssa_1 is unused and should be removed but nir dce doesnt remove that, once nir_lower_vec_to_movs runs, they become really unused

21:05 <enunes> in your (un)lucky case it was an undef node and caused the crash

21:05 <enunes> but we should really run nir dce after nir_lower_vec_to_movs

22:55 <enunes> linkmauve: this passed all my tests so https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9507