07:14 dj-death: someone understand what the value computed by gl_SubGroupLtMaskARB means?
07:14 dj-death: The nir_intrinsics.py has : subgroup_lt_mask bit index < subgroup_invocation
07:16 dj-death: each lane computes a 0/1 based on its on... what? < subgroup_invocation
07:45 glehmann: for each invocation, it contains the bit mask of invocations with a smaller invocation_id
07:47 glehmann: so 0 for invocation 0, 0x1 for 1, 0x3 for 2, 0x7 for 3, ... 0x7fff'ffff for invocation 31
07:48 dj-death: glehmann: thanks
14:19 dj-death: is there a way to condition an rule to some operation done on 2 of the constant pattern matched in opt_algebraic?
14:20 dj-death: like I have inot(iand(ior(a, 0x40), 0x40))
14:20 dj-death: that's true
14:20 dj-death: but I don't know what would clean that up
14:24 dj-death: I guess I would need a custom is_... callback fishing out the other constant and doing the test
14:28 karolherbst: I was looking into weird things like that
14:33 pendingchaos: you can require that two constants are the same, so iand(ior(a, #b), #b) -> #b
14:33 dj-death: they're not the same
14:33 dj-death: they might just AND properly such that the ior can be ignored
14:37 vsyrjala: you're saying 0x40 != 0x40 ?
14:37 karolherbst: yeah... I wanted to know the relationship about two constants used in expression for ishl+ushr patterns where I'd like to simplify it to a single op
14:37 dwfreed: they're not *necessarily* the same, is what I think they mean
14:38 pendingchaos: iand(ior(a, #b), #c) -> #c if b & c == c
14:39 glehmann: https://gitlab.freedesktop.org/mesa/mesa/-/work_items/2635 there is an ancient issue about this
14:41 karolherbst: yeah... I think this would be super helpful. Maybe we should add another argument to the patterns where one can declare a restriction on the values?
14:42 karolherbst: or...
14:42 karolherbst: we make constant available to the current one
14:44 robclark: https://www.irccloud.com/pastebin/x4Q6p2JU/
14:44 robclark: karolherbst: ^^^
14:45 karolherbst: robclark: looks pretty correct to me? Is it the same with and without that patch?
14:47 robclark: karolherbst: yeah, looks the same.. not really sure why it fails at runtime
14:48 karolherbst: robclark: does it work if you remove the "c->getHeaderSearchOpts().ResourceDir = clang_res_path.string();" line?
14:49 karolherbst: there is also clang_install_res_path but I _highly_ doubt that path gets changed?
14:49 karolherbst: though.....
14:49 karolherbst: maybe it does?
14:51 robclark: removing that line doesn't seem to change anything
14:57 karolherbst: robclark: and clang_install_res_path is also the same with and without that patch? But I honestly don't see how that patch would impact anything there...
14:58 robclark: yes, same
14:58 karolherbst: what's the error anyway? clang not finding that opencl-c-base.h file?
14:59 robclark: kernels fail compile with an error about not finding opencl-c-base.h
15:00 karolherbst: maybe some weird incompatibility issue somewhere... but I also don't really see why a static libstdcpp would really triggers this on a debian system, given LLVM is probably build against the same, just dynamically?
15:00 karolherbst: but also don't like the solution...
15:00 robclark: karolherbst: unrelated, seems like all the subgroup tests skip because we don't have CL_DEVICE_WORK_GROUP_COLLECTIVE_FUNCTIONS_SUPPORT ?
15:01 karolherbst: maybe we should just not use std::fs at all instead and revert to dynamic linking
15:01 karolherbst: robclark: subgroups/test_subgroups ?
15:01 robclark: yeah
15:02 karolherbst: it.. shouldn't skip because of that tho...
15:02 karolherbst: but the subgroup test also never reads that query
15:03 robclark: check InitCL() in test_conformance/workgroups/main.cpp.. tho that doesn't seem to be new.. hmm
15:04 karolherbst: that's not the subgroup check
15:04 karolherbst: *test
15:04 karolherbst: test_subgroup, not test_workgroup
15:05 robclark: ahh, doh
15:40 karolherbst: robclark: that should resolve the libstdc++ problem https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41488
15:44 robclark: that seems to fix it for me
15:44 karolherbst: cursed
15:50 pendingchaos: dj-death, karolherbst: so here's something: https://gitlab.freedesktop.org/pendingchaos/mesa/-/commits/nir_search_transform_cond
15:50 pendingchaos: maybe it would be nice to have a mode which uses type information of the search/replace expression to create that loop for you so it can just be "(('iand', ('ior', a, '#b'), '#c'), c, when('(b & c) == c'))"
15:51 pendingchaos: also no idea if this works with the nir_algebraic test stuff
15:51 karolherbst: mhhh, yeah that's kinda what I had in mind
15:54 karolherbst: would be nice if we could also wire up uub and range analysis, but I can play around with at some point
15:55 pendingchaos: nir_search_state is passed through, so uub/range analysis is available with if the function in nir_search_helpers.h uses it
15:55 pendingchaos: well, range/numlsb analysis actually, but uub is trivial to add
16:04 karolherbst: yeah... I was considering adding x << a >> b -> x << (a - b) when a > b and x << a >> b -> x >> (b - a) when b > a patterns depending on if the shifts wrap (though for that we can just set the nuw, nsw flags) and depending on a and b
16:19 pendingchaos: I guess passing the ishl/ishr instruction to the function would probably be best for that, but that requires more work
16:20 pendingchaos: so you can check for both the nuw flag and the uub of the sources if the flag isn't set
16:20 karolherbst: yeah... I played around with some ideas but I didn't like either solution