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!
nerdboy has quit [Excess Flood]
nerdboy has joined #lima
nerdboy has quit [Changing host]
nerdboy has joined #lima
Da_Coynul has joined #lima
megi has quit [Ping timeout: 248 seconds]
yuq825 has joined #lima
jrmuizel has quit [Remote host closed the connection]
jrmuizel has joined #lima
Da_Coynul has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
kaspter has joined #lima
kaspter has quit [Ping timeout: 244 seconds]
kaspter has joined #lima
<wens> anarsoul: I'm already doing clean builds, since I cross compile for both arm and arm64
jrmuizel has quit [Remote host closed the connection]
nerdboy has quit [Ping timeout: 268 seconds]
nerdboy has joined #lima
<anarsoul> yeah, glmark2-drm doesn't work for me either :\ kmscube or weston work fine though
<anarsoul> adding "--visual-config stencil=1:alpha=0" to glmark2 cmdline helps
nerdboy has quit [Ping timeout: 268 seconds]
camus has joined #lima
kaspter has quit [Ping timeout: 246 seconds]
camus is now known as kaspter
camus has joined #lima
kaspter has quit [Ping timeout: 246 seconds]
camus is now known as kaspter
dddddd has quit [Remote host closed the connection]
Barada has joined #lima
monstr has joined #lima
kaspter has quit [Quit: kaspter]
kaspter has joined #lima
kaspter has quit [Quit: kaspter]
kaspter has joined #lima
guillaume_g has joined #lima
kaspter has quit [Quit: kaspter]
guillaume_g has left #lima [#lima]
kaspter has joined #lima
megi has joined #lima
<rellla> i have a general question about undefs... what is the expected result of e.g. gt(ssa0, undef)?
<rellla> is it 0.0/1.0 or something undefined? just to be clear...
<anarsoul> undef
<anarsoul> gt(ssa0, undef) = undef
<rellla> ok thanks. did you want to ping me yesterday?
<anarsoul> sorry, I forgot what was the question
<anarsoul> (and it was today for me :P)
<rellla> :)
<bshah> I wonder anyone have any fancy ideas for https://gitlab.freedesktop.org/lima/mesa/issues/101 ? :)
<anarsoul> bshah: not yet
<anarsoul> I may have some time this weekend to look into it
<bshah> okay, cool :)
<anarsoul> I can't promise that I'll fix it though
<anarsoul> could be some complex issue
<bshah> sure, if I know what causes the issue I can try to workaround it on my side as well, but otherwise I am kinda flying in blind :/
<anarsoul> enunes: unfortunately cloning/pipelining uniforms and ldtex regresses some shaders, they fail in regalloc
<anarsoul> your branch may fix it though, I'll try tomorrow
<anarsoul> (in ~18h)
<anarsoul> regressions were already spilling
<anarsoul> and I don't understand how my changes could increase reg pressure, they're supposed to decrease it
<enunes> anarsoul: my branch fixed a few tests, removing the forced vec4 also helped and seemed to cause no regressions
<enunes> strange to me too that cloning uniforms would have no impact, or even bad impact, on register pressure
guillaume_g has joined #lima
guillaume_g has left #lima [#lima]
kaspter has quit [Read error: Connection reset by peer]
kaspter has joined #lima
kaspter has quit [Ping timeout: 244 seconds]
kaspter has joined #lima
yuq825 has quit [Quit: Leaving.]
Da_Coynul has joined #lima
Da_Coynul has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
Da_Coynul has joined #lima
Da_Coynul has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
Da_Coynul has joined #lima
megi has quit [Ping timeout: 246 seconds]
Da_Coynul has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
<MoeIcenowy> anarsoul: pp fault still exist on X
<MoeIcenowy> master (looks like texture descriptor fix is merged)
<MoeIcenowy> and the X server cannot recover from the fault, the display content cannot change since then
yuq825 has joined #lima
jrmuizel has joined #lima
jrmuizel has quit [Remote host closed the connection]
yuq825 has quit [Ping timeout: 246 seconds]
yuq825 has joined #lima
kaspter has quit [Quit: kaspter]
yuq825 has quit [Quit: Leaving.]
<rellla> enunes: how do you deal with crashing piglit shaders within shader-db run?
jrmuizel has joined #lima
dddddd has joined #lima
yuq825 has joined #lima
UnivrslSuprBox has joined #lima
<enunes> rellla: if it's a known crash not caused by my modifications I remove it from the list so I can work on the thing I want to work in
<enunes> I just move the shader_test file to a 'disabled' directory
Barada has quit [Quit: Barada]
yuq825 has quit [Quit: Leaving.]
<anarsoul> MoeIcenowy: well, then debug it :)
megi has joined #lima
<MoeIcenowy> anarsoul: try to LIMA_DEBUG=gp,pp,dump
<MoeIcenowy> and it segfaults when doing command stream dump
<MoeIcenowy> ??!!
<anarsoul> that's not good
tbueno has joined #lima
<anarsoul> MoeIcenowy: grab coredump and see where it crashed?
<MoeIcenowy> anarsoul: got a dump w/o crashing
nerdboy has joined #lima
nerdboy has quit [Changing host]
nerdboy has joined #lima
<anarsoul> MoeIcenowy: I'm also interested in crash, can you get coredump and then backtrace with gdb?
drod has joined #lima
drod has quit [Ping timeout: 272 seconds]
drod has joined #lima
<MoeIcenowy> anarsoul: inside lima_dump_blob()
<anarsoul> MoeIcenowy: what line number?
<MoeIcenowy> src/gallium/drivers/lima/lima_util.c:63
<MoeIcenowy> 200859f45cf96b3fdc58667242ec79937072337d
<anarsoul> can you show backtrace?
<anarsoul> where lima_dump_blob() is called from?
hoijui has joined #lima
<anarsoul> MoeIcenowy: ?
sunxi_fan has joined #lima
<anarsoul> cwabbott: looks like standalone compiler produces totally different result from the driver in some cases
<anarsoul> i.e. don't see array reg (i.e. decl_reg vec4 32 r0[8]) in driver when running glsl-fs-vec4-indexing-temp-src-in-loop
<anarsoul> but it's here in standalone compiler
<anarsoul> any ideas why?
<anarsoul> i.e. nir representation of glsl shader is different
sunxi_fan has quit [Quit: Leaving.]
libv_ has joined #lima
monstr has quit [Remote host closed the connection]
<anarsoul> enunes: regressions that I saw yesterday came from your vectorization changes
<anarsoul> e.g. glsl-fs-vec4-indexing-temp-src-in-loop now lowers fcsel ssa_32.xxxx, ssa_17, ssa_16 into 4 fcsels
<enunes> yeah thats expected
libv has quit [Ping timeout: 272 seconds]
<anarsoul> yeah, but now it fails in regalloc
<enunes> so same problem we have to fix for ideas?
<anarsoul> are you planning to address it? it should be easy to detect in lower_to_scalar pass, just add an option to do that
<anarsoul> unlikely
<anarsoul> looks like there's no selects in this shader
<enunes> I see it more as a feature and maybe it would fix the particular problem, but for some reason we are ending up with regalloc very difficult to solve in general
<enunes> I can work on it after the spilling improvements though
<enunes> the vec fcsel with scalar condition
<anarsoul> maybe it's not relevant atm
<anarsoul> I'm not sure how to fix spilling though
<enunes> I don't think spilling is the problem
<anarsoul> in ideas?
<enunes> yes, with the latest changes we basically remove all instruction creation, and it still doesn't work
<anarsoul> I haven't set up shader-db yet so I'd be grateful if you can run it for me :)
<enunes> sure, I should be able to run it quickly
<anarsoul> I'm also working on merging branch conditions into branch instruction but it doesn't work well yet
<anarsoul> there's some corner cases
<anarsoul> (as usual)
<anarsoul> it should reduce instruction count for affected shaders but it won't affect reg pressure
hoijui has quit [Ping timeout: 264 seconds]
<enunes> this is even without my spilling improvements, although it seems that spilling is much less required with this change
<anarsoul> looks like it hurt some shaders
<anarsoul> hm
<enunes> pretty hard to have 0 hurts
<anarsoul> true
<enunes> I guess I can take my changes out of WIP now
<anarsoul> btw, can you share your shader-db shaders somewhere? maybe start a git repo for them?
<enunes> I can, but they would get outdated quickly, it's pretty easy to generate the list
<enunes> basically run piglit once with MESA_SHADER_CAPTURE_PATH=$PWD/somewhere
<anarsoul> how do you filter out those that fail?
<enunes> they just fail in shader-db if it crashes, if it fails in runtime shader-db doesn't know about it
<enunes> I just move them from the captured shaders repo to a 'disabled' repo if they crash
<enunes> and it's not a regression I introduced
libv_ is now known as libv
<anarsoul> enunes: I think we should also favor spilling SSAs over regs
<enunes> yeah I thought about that but it would probably provide very marginal gain again
<anarsoul> yet it should improve shaders with a lot of regs
<anarsoul> it's beneficial to spill one vec4 ssa, it essentially turns it into uniform
<enunes> I can give it a try
<anarsoul> which can be inserted anywhere
<enunes> though at this point it's very empirical to come up with costs
<anarsoul> yeah
<enunes> say I multiply regs to 1.5 for example, and then it decides to spill a ssa with less components and more uses, then it hurts some of the cases
<anarsoul> yeah
<anarsoul> I think we should write it down somewhere
<anarsoul> so it can be analyzed better
<anarsoul> probably a comment in regalloc.c with explanation what affects spilling cost?
<enunes> honestly so far it's all empirical, I try multiple values and pick whatever seems to be better
<enunes> but once we start getting to 3+ variables, not even sure how to define them
<anarsoul> I understand, but it would be nice to have something like:
<enunes> maybe what we can have is a deciding benchmark, like the glamor shader
<anarsoul> spilling cost: vec1: 4, vec2: 2, vec3: 3, vec4: 1. Modifiers: used in instructions with uniform slot taken: 1.1x, used in instructions with store slot taken: 1.1x, register: 1.1x
<enunes> and optimize for that even if it hurts some unimportant piglit shaders
<anarsoul> do we spill in glamor shaders?
<enunes> right now the base cost is actually 1/(num_components), I tried to made that (5.0 - num_components) and that hurt more shaders than helped
<anarsoul> it used to be 4.0f/num_components
<enunes> oh yeah sorry 4.0
<enunes> I thought we do? I still didn't include glamor in my list actually
<anarsoul> unlikely, they're pretty simple shaders
<enunes> ok it seems that shader-db itself includes glamor shaders, so I don't need to capture them
<anarsoul> I tried the most complex with standalone compiler and it doesn't spill
<anarsoul> 73.shader_test
<anarsoul> oops, wrong one
<enunes> well this one is complicated shaders/glamor/88.shader_test - MESA_SHADER_FRAGMENT shader: 782 inst, 1 loops, 30:166 spills:fills
<anarsoul> 85.shader_test.frag does spill
<anarsoul> and regalloc fails :(
ecloud has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
<anarsoul> even with your changes
ecloud has joined #lima
<anarsoul> btw, what is select_reg_callback?
<enunes> haven't used it, seems to be to have some influence in the order of choosing nodes during regalloc
<anarsoul> enunes: looks like function values are returned as individual components, i.e. if function returns vec3 it's returned in 3 vec1 regs
<anarsoul> that hurts us a lot
<anarsoul> we need to recombine them somehow
<anarsoul> it's coming from nir_lower_phis_to_scalar
<anarsoul> ha, that's better
<anarsoul> enunes: try commenting out nir_lower_phis_to_scalar pass in lima_program.c for fs
jrmuizel has quit [Remote host closed the connection]
drod has quit [Remote host closed the connection]
Da_Coynul has joined #lima