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/
jelly has joined #lima
Leopold__ has joined #lima
Leopold has quit [Ping timeout: 480 seconds]
<anarsoul> enunes: have you had a chance to look into why migrating to nir_legacy hits shader-db so badly?
<enunes> anarsoul: nope, still trying to figure out gpir
<enunes> I think one of the many reasons is that dummy node to be created so that a register exists in the var_nodes stuff
<enunes> but I didn't really do any sort of analysis of what goes on with the registers now
<anarsoul> I see
<enunes> we should probably move to the chasing helpers strategy when we can and drop the now-legacy stuff I guess
<enunes> but with the time at hand, not sure really when that would happen after this initial push
<anarsoul> yeah, but mali4x0 isn't the fastest GPU
<anarsoul> with 20% perf regression we'll get a lot of bug reports once it gets into the next release
<enunes> yep, so we might need some help if we are to stop being the blocker for this
<enunes> anarsoul: wow how come this wasn't hit before https://gitlab.freedesktop.org/mesa/mesa/-/jobs/46264712#L4995
<enunes> shader writes to gl_FragDepth which is a float...
<enunes> I think we don't support that, still it's an assert which stops shader-db
<anarsoul> no idea
<anarsoul> gl_FragDepth still should be in .xyz
<anarsoul> oh, or in .x
<anarsoul> but yeah, it doesn't have a swizzle
<anarsoul> so it probably needs a mov?
<anarsoul> enunes: see how we handle nir_intrinsic_store_output
<anarsoul> nope, it's all in regalloc
<anarsoul> so basically if we set out_reg we have additional constraint on what register we can use
<anarsoul> anyway, we can just hack it in nir.c
<anarsoul> even if it's just a float (as in case of gl_FragDepth), we still need a whole vec4 reg
<enunes> still trying to finish the register intrinsic stuff, I just threw that at CI to see if enabling shader-db there would be that one line
<anarsoul> so write_mask should be u_bit_consecutive(0, 4); regardless of num_components
<anarsoul> it's a bug in existing code
<anarsoul> I'd say we can't set node->is_out for anything but color output
<anarsoul> it has to be a mov, and dest should be a vec4 register