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 and - Contact ARM for binary driver support!
_whitelogger has joined #lima
kaspter has joined #lima
kaspter has quit [Excess Flood]
kaspter has joined #lima
chewitt has joined #lima
smaeul has joined #lima
putti_ has joined #lima
Putti has quit [Remote host closed the connection]
mmind00 has quit [Quit: No Ping reply in 180 seconds.]
bhoj- has joined #lima
daniels has quit [Ping timeout: 240 seconds]
bhoj has quit [Read error: Connection reset by peer]
daniels has joined #lima
robher has quit [Ping timeout: 240 seconds]
robher has joined #lima
chewitt has quit [Quit: Adios!]
Barada has joined #lima
monstr has joined #lima
Barada has quit [Quit: Barada]
Elpaulo has joined #lima
monstr has quit [Quit: Leaving]
monstr has joined #lima
Net147 has quit [Quit: Quit]
Net147 has joined #lima
_whitelogger has joined #lima
kaspter has quit [Ping timeout: 246 seconds]
kaspter has joined #lima
mmind00 has joined #lima
dev1990_ has quit [Quit: Konversation terminated!]
<enunes> linkmauve: I experimented a bit with the gtk4 shaders, I noticed that pretty much all shaders end up fairly big and suboptimal also due to gsk/resources/glsl/preamble.fs.glsl
<enunes> linkmauve: for example: compiling the fragment shaders from super mario 64 average 10 instructions, shaders from glmark2 30-100 instructions
<enunes> linkmauve: shaders from gtk4, 300-700 instructions
<enunes> still on my system I get 20-30 fps with gtk4 and I dont get the glitch in your screenshot
<enunes> but also hacking around to simplify the gtk4 shaders doesn't change that much, there may be some bottleneck somewhere else and that would require a closer look, maybe the way gtk4 is rendering causes too many framebuffer reloads which kills performance with the mali
Barada has joined #lima
Barada has quit [Quit: Barada]
<linkmauve> enunes, if the functions in the preamble aren’t used they will be optimised away, so I would suppose that’s a red herring.
<linkmauve> Do you have a env var to dump annotated shader assembly btw?
<linkmauve> I’ve used that in iris in the past to know what to optimise in my shaders.
uis has joined #lima
<enunes> linkmauve: in lima there is LIMA_DEBUG=pp,gp,shaderdb for fragment shader, vertex shader and shaderdb-like summary statistics respectively
<enunes> for a quicker turnaround on shader analysis I dumped shaders with and you can test compile the output with
<linkmauve> Neat!
<linkmauve> That way I don’t need to rebuild GTK on the Switch, scp the package, install it on the PinePhone or the Olimex, and run it with Lima!
<linkmauve> Speaking of Olimex, I get the jumpy vertices on both A10 and A20, despite the different GPU revisions. :/
<enunes> jumpy vertices you mean the glitched output from the screenshot?
kaspter has quit [Quit: kaspter]
dev1990 has joined #lima
monstr has quit [Remote host closed the connection]
enty is now known as ente
gcl_ is now known as gcl
enty has joined #lima
ente has quit [Read error: Connection reset by peer]
putti__ has joined #lima
putti_ has quit [Ping timeout: 265 seconds]