00:07 phomes_[d]: gfxstrand[d]: so those CS2 benchmarks are not consistent. At least not on nvk. I was writing a script to automate running it and found that even for the same driver multiple runs would vary with more that 10 fps
00:08 gfxstrand[d]: That's okay. If you can get something more stable, great. If not, we'll say it maybe helps and probably isn't a regression and call it good.
00:15 karolherbst[d]: phomes_[d]: we really need to disable block boosting to get reliable numbers for benchmarks
00:15 karolherbst[d]: *clock
02:33 redsheep[d]: Some benchmarks are just really hard to get consistent. Even making sure to warm the shader cache and isolate all the variables just isn't enough for some programs to not have variance
02:35 sonicadvance1[d]: Even a consistent benchmark like nbench/bytemark can have like 10% swings 😛
04:03 x512[m]: Run multiple times and calculate avg and std dev?
07:29 karolherbst[d]: benchmarking is very hard, but variable clocks just make it even harder 😛
07:43 redsheep[d]: Depending on your exact gpu clock can get pretty consistent after several runs once the cooler is at steady state, but yeah being able to actually lock them would be nice
07:47 karolherbst[d]: yeah, but also CPU clocks
07:50 redsheep[d]: Annoyingly I am not sure it's even possible to get my cpu into a configuration that will be consistent. I have a 7950x3d, so I could set fixed clocks but I am not aware of any controls that let me force games to only run on vcache threads.
07:51 sonicadvance1[d]: taskset, most games don't mess with affinity
07:51 sonicadvance1[d]: If that doesn't work, offline the other cores 😄
07:54 redsheep[d]: Yeah I suppose if I am going as far as fixed clocks no reason to leave cores online that could lead to bad data
14:44 phomes_[d]: running the benchmark multiple times and taking avg and std dev makes sense
14:45 phomes_[d]: I had already provided some quick benchmark data in an MR and just wanted to flag that the results should be taken more as a soft indication rather than real evidence
14:46 phomes_[d]: Warhammer 3 went on sale so I got that to benchmark with. For the "Remove nir_jump_continue" MR the results look identical before/after
16:11 marysaka[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1484585204961247344/image.png?ex=69bec337&is=69bd71b7&hm=775297a79b91b6920659ff9e250990bda77f859cff0884b57c3c0165808bac26&
16:11 marysaka[d]: gfxstrand[d]: I'm reading `nir_intrinsics.py` and it says that `load_helper_invocation` shouldn't be reorderable but we assume in the lowering that we can reorder it and the comment for `nir_intrinsic_is_helper_invocation` mention that too... who is right here?
16:12 marysaka[d]: (Was looking at FSI a bit and saw that but seems unrelated to the regressions I have on main)
16:12 gfxstrand[d]: Ugh... Give me a minute. This one's going to require archeology.
16:13 marysaka[d]: no worries!
16:23 gfxstrand[d]: Okay, so `is_helper_invocation` definitely can't be re-ordered.
16:24 gfxstrand[d]: But the other is more questionable.
16:25 marysaka[d]: yeah I'm not too sure that's why I asked just in case this could be a problem 😅
16:29 gfxstrand[d]: For the system value, **OpDemoteToHelperInvocation** says:
16:29 gfxstrand[d]: > After an invocation executes this instruction, any subsequent load of **HelperInvocation** within that invocation will load __poison__ unless the **HelperInvocation** __built-in variable__ is __decorated__ with **Volatile** or the load included **Volatile** in its **Memory Operands**
16:29 gfxstrand[d]: So it's safe to move up but not down past an `OpKill`
16:30 gfxstrand[d]: So, yeah, I guess that means we shouldn't re-order unless we just re-order them all to the top or something.
16:30 gfxstrand[d]: And it's frustrating because what CSE will do is always correct.
16:31 gfxstrand[d]: But we don't have a way to express more nuanced dependencies in NIR
16:33 marysaka[d]: so I guess I will make a MR
16:34 marysaka[d]: I have some regressions from the load_global_nv ect changes with dead_cf as that pass isn't aware of it
16:54 marysaka[d]: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40543
19:46 karolherbst[d]: the schedulers are sometimes doing weird things...
21:03 gfxstrand[d]: Schedulers will do that
21:04 karolherbst[d]: I wished they wouldn't tho
21:04 karolherbst[d]: but I'm sure we could tweak ours in NAK to be a bit better
21:08 karolherbst[d]: seems like running `opt_remove_phis` earlier gives some nice benefits..
21:08 karolherbst[d]: I like that shaders only improve and no regressions
21:36 karolherbst[d]: ... I've reached the "what's wrong with `nir_opt_loop_unroll`" stage...
22:23 karolherbst[d]: mhhh
22:23 karolherbst[d]: soo..
22:24 karolherbst[d]: why is that so complicated, who tells me the perfect pass order 😄
23:04 karolherbst[d]: I wonder if we should loop unroll more aggressively, that seems to help