ChanServ changed the topic of #lima to: Development channel for open source lima driver for ARM Mali4** GPUs - Kernel driver has landed in mainline, userspace driver is part of mesa - Logs at https://oftc.irclog.whitequark.org/lima/
ity has quit [Remote host closed the connection]
tanty has quit [Ping timeout: 480 seconds]
ity has joined #lima
tanty has joined #lima
chewitt has joined #lima
Daanct12 has joined #lima
tlwoerner_ has quit []
tlwoerner has joined #lima
Daanct12 has quit [Ping timeout: 480 seconds]
Daanct12 has joined #lima
Daanct12 has quit [Ping timeout: 480 seconds]
linkmauve has left #lima [Error from remote client]
linkmauve has joined #lima
tanty has quit [Quit: Ciao!]
tanty has joined #lima
tanty has quit []
tanty has joined #lima
fomys_ has quit [Read error: Connection reset by peer]
fomys has joined #lima
sarbes_ has joined #lima
sarbes_ has quit []
<enunes> sarbes: did you run the recent MR through shader-db? I think would be useful to mention there if it saves an instruction in any of those shaders or just has no diff
<enunes> I guess it might not save since it would be a const, but anyway, seems like a nice feature added there
<anarsoul> It should reduce the code size, but I don't expect it to save any cycles. Loading from constant reg is essentially free
chewitt has quit [Ping timeout: 480 seconds]
chewitt has joined #lima
<sarbes> test
<sarbes> Ah, I'm authenticated now.
<sarbes> I've run the shader-db now, but I'm not sure what to make of it: https://paste.centos.org/view/bed0cb32
chewitt has quit [Read error: Connection reset by peer]
chewitt has joined #lima
<sarbes> That's with a GL 3.0 override.
<sarbes> There seems to be no support for GL_EXT_shader_texture_lod
<sarbes> So for plain GLES 2.0, only the bias seems interesting.
chewitt has quit [Read error: Connection reset by peer]
chewitt has joined #lima
chewitt has quit []
chewitt has joined #lima
chewitt has quit []
<enunes> there should be no need to override with GL 3.0
<enunes> is that a diff between main and your branch?
<enunes> LOST is pretty bad, means it broke compilation for that shader
mripard_ has joined #lima
mripard__ has joined #lima
mripard has quit [Ping timeout: 480 seconds]
mripard_ has quit [Ping timeout: 480 seconds]
<sarbes> Eh, maybe the override messed things up. Here is a fresh run: https://paste.centos.org/view/4e8d77ce
<sarbes> No LOST anymore :)
<sarbes> I've commented out my change for the comparison.
<enunes> that seems pretty good for the affected shaders, maybe too good? :) hope it hasn't introduced an issue for them. saving over 10 instructions with this change seems a bit too good to be right
<sarbes> Yeah. Maybe I should rite more tests?
<sarbes> Is there any way to get the shader binary?
<enunes> I would suggest to start by picking one of the affected shaders and run shader-db with LIMA_DEBUG=pp and diff it against the same thing against main and take a look at the output
<enunes> so something like $ LIMA_DEBUG=pp ./run shaders/godot3.4/34-59.shader_test > main and then with your branch
<sarbes> I can give you the output of shaders/godot3.4/37-58.shader_test if you want. It looks right to me.
<sarbes> GLSL optimizer reduces it to this: https://paste.centos.org/view/99c5e57f
<sarbes> Before the change, this is the shader output: https://paste.centos.org/view/9f84f7bd
<sarbes> From my understanding, the const load is happening later than texturing in the pipeline. So the texture unit has to wait for the second cycle in order to get the constant LOD originally.
<sarbes> Any by supplying the constant via the instruction, the first cycle containing just the constant load+mov can be avoided.
<sarbes> Or maybe I'm misreading the output.