ChanServ changed the topic of #lima to: Development channel for open source lima driver for ARM Mali4** GPUs - Kernel has landed in mainline, userspace driver is part of mesa - Logs at https://people.freedesktop.org/~cbrill/dri-log/index.php?channel=lima and https://freenode.irclog.whitequark.org/lima - Contact ARM for binary driver support!
kaspter has quit [Ping timeout: 245 seconds]
kaspter has joined #lima
Tooniis has quit [Ping timeout: 240 seconds]
apol has quit [Ping timeout: 240 seconds]
apol has joined #lima
Tooniis has joined #lima
camus has joined #lima
kaspter has quit [Ping timeout: 245 seconds]
camus is now known as kaspter
tlwoerner has quit [Remote host closed the connection]
tlwoerner has joined #lima
jernej has quit [Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net]
jernej has joined #lima
kaspter has quit [Ping timeout: 246 seconds]
kaspter has joined #lima
kaspter has quit [Quit: kaspter]
kaspter has joined #lima
_whitelogger has joined #lima
Barada has joined #lima
camus has joined #lima
kaspter has quit [Ping timeout: 264 seconds]
camus is now known as kaspter
kaspter has quit [Ping timeout: 264 seconds]
kaspter has joined #lima
kaspter has quit [Remote host closed the connection]
kaspter has joined #lima
dev1990 has joined #lima
Barada has quit [Quit: Barada]
kaspter has quit [Ping timeout: 245 seconds]
kaspter has joined #lima
Barada has joined #lima
Barada has quit [Quit: Barada]
warpme_ has joined #lima
camus has joined #lima
kaspter has quit [Remote host closed the connection]
camus is now known as kaspter
bshah_ is now known as bshah
kaspter has quit [Ping timeout: 246 seconds]
kaspter has joined #lima
kaspter has quit [Ping timeout: 276 seconds]
kaspter has joined #lima
camus has joined #lima
kaspter has quit [Ping timeout: 246 seconds]
camus is now known as kaspter
kaspter has quit [Read error: Connection reset by peer]
kaspter has joined #lima
kaspter has quit [Quit: kaspter]
<linkmauve> enunes, the main bottleneck in GTK 4 is actually the rounded rectangle clipping computation.
<linkmauve> Removing that from gskSetOutputColor() makes the fragment shader go from 114 instructions down to just a single one.
<enunes> linkmauve: hmm ok nice to hear some progress, now is that something that can be left out, or is it expected that particularly lima should optimize on something?
<linkmauve> I’m fixing it in GTK, atm to at least use a different shader for non-clipped draw calls.
<linkmauve> Making a theme which doesn’t use round rectangles would probably optimise things further a bit.
<linkmauve> enunes, for the gradient though, would it make sense to specialise shaders based on the uniform used for the loop counter?
<linkmauve> I can also fix that in GTK, since in the default theme it only ever uses two colour stops I can write a shader for that.
<linkmauve> /tmp/foo/33.shader_test - MESA_SHADER_FRAGMENT shader: 441 inst, 1 loops, 21:58 spills:fills
<linkmauve> /tmp/bar/33.shader_test - MESA_SHADER_FRAGMENT shader: 394 inst, 0 loops, 5:7 spills:fills
<enunes> linkmauve: I think it could help since it would allow unrolling them at compile time, but after my last try I'm not convinced yet that it would lead to an actual increase in performance so probably needs some experimentation too
<linkmauve> That’s what I get when I replace the uniform with a fixed 2.
<enunes> wow that is a complicated shader
<linkmauve> There are comparatively few elements that are rendered with a gradient in Adwaita.
<linkmauve> /tmp/baz/33.shader_test - MESA_SHADER_FRAGMENT shader: 52 inst, 0 loops, 0:0 spills:fills
<linkmauve> It becomes that with both the uniform replaced with 2 and without the round rect.
<linkmauve> Suddenly much less complicated. ^^
<enunes> yeah this is much more reasonable, and it doesnt spill at all which should already be much better
<linkmauve> But now GTK people are at least aware of the issue, and are throwing suggestions at me. :)
<enunes> I guess it can be easy to program shaders like normal C code without realizing how that will end up in an embedded gpu like this
<linkmauve> Yeah. ^^'
<linkmauve> And even on desktop it can probably lead to being much slower than possible.
<linkmauve> Scrolling as fast as I can currently takes 1.5 W on my Intel.
<linkmauve> And 13% (whatever that means) of the GPU.
<linkmauve> Without rounded rect clipping, that’s now 200 mW and 17%.
<linkmauve> Vs. ~90 mW and 1% in “idle”.
<anarsoul> linkmauve: hehe
<anarsoul> linkmauve: likely it runs at higher freq when it consumes 1.5W
<linkmauve> Sure.
<anarsoul> that would explain 15% vs 17%
<linkmauve> Just a datapoint to help GTK people realise it isn’t an issue only on mobile. :)
<anarsoul> get them a raspberry pi? one with older GPU (vc4) - that one is the same class as mali4x0
<anarsoul> I'm pretty sure it'll stutter as well with complicated shaders
<linkmauve> I don’t think I’ve ever heard them test on that one.
<linkmauve> Maybe that sbc isn’t popular in this crowd?
<anarsoul> raspberry pi?
<anarsoul> I think it's the most popular SBC
<anarsoul> rpi1-3 has vc4 gpu while rpi4 has more powerful v3d
<linkmauve> I mean, among GTK devs.
kaspter has joined #lima
kaspter has quit [Remote host closed the connection]
kaspter has joined #lima
kaspter has quit [Client Quit]
warpme_ has quit [Quit: Connection closed for inactivity]
adjtm has joined #lima