00:06karolherbst: robclark: uhh.. I think I know which issue that is.. I kinda thought I fixed it
00:07karolherbst: there is a use-after-free on the function_impl or something...
00:31karolherbst: robclark: https://gist.githubusercontent.com/karolherbst/466b20e50eaf9c58eb9b0b2ba0866f14/raw/55462289cbf0d77959887f580a1c5029053381be/gistfile1.txt
00:31karolherbst: won't fix it today, but maybe tomorrow if you don't
00:32karolherbst: but I thought I had a patch for that...
00:34karolherbst: do we forget to reparent `instr->callee` or something...
00:36karolherbst: but that would be odd..
00:44karolherbst: ahhh.. the libclc doesn't have a definition for "_Z37__clc_flush_denormal_if_not_supportedf"
00:45karolherbst: so it's a libclc bug ðŸ˜
00:45karolherbst: but we should also handle this more gracefully
08:16dolphin: airlied, sima: sent drm-intel-fixes PR
14:48karolherbst: I need some IEEE float math experts.. assuming we have an instruction that does `a * b * c` where c is constant (we have 1/8 up to 8 in POT steps), but the instruction is supposed to not do intermediate rounding/flushing of denorms. Does it matter if c is applied to `a`, to `b` or to `a * b`?
14:49karolherbst: or would it be truly associative?
14:58karolherbst: I guess it could impact some edge case numerical precision around extreme values...
14:58glehmann: not sure I understand the question. if there is no rounding inbetween it's associative by definition. Or are you asking which pattern you can match to that instruction? Then the answer is none if you are strict, or all of them if contraction is allowed
14:58karolherbst: yeah... not sure either
14:59karolherbst: we have a post divider on FMUL, but I try to figure out if it's applied to a source or the product of both, but everything indicates that it's done with infinite precision
14:59karolherbst: so I wonder what would be the easiest way to verify it
15:02glehmann: a = FLT_MAX, b = 0.5, c = 2.0 would not return FLT_MAX if c is applied to a first with rounding
15:02karolherbst: I know for a fact that c is applied without rounding
15:03karolherbst: I'm wondering if it matters if it applies to a, or b or a * b
15:03karolherbst: that's the part I don't know, but my gut feeling says it also doesn't matter
15:03glehmann: without rounding is the same as infinite precision and then it wouldn't matter at all because infinitely precise mul is associative
15:03karolherbst: right
15:04karolherbst: yeah, mostly asking in case I'm missing something here
15:18karolherbst: glehmann: if we have contract set, can we optimize `fmul(fmul(a, b), c)` if the intermediate result could be `inf`? Technically it makes the operation more precise, but it also changes semantics around Inf, so I'm wondering what the rules are
15:19karolherbst: but probably best to make it an exact transformation...
15:19glehmann: contract is enough, same as for fma
15:20glehmann: see https://registry.khronos.org/vulkan/specs/latest/html/vkspec.html#spirvenv-evaluation-expressions
15:22karolherbst: cool, thanks
16:12karolherbst: zmike: seems like https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/42562/diffs?commit_id=97a97300490197d7985c0a1fa79dc29dff98f232 regresses e.g. "test_conformance/atomics/test_atomics atomic_add" and I was wondering if you have any ideas what to try or check before I start debugging
19:37karolherbst: robclark: okay.. I've fixed this crash on the libclc by turning "inline float __clc_flush_denormal_if_not_supported" into "static inline float __clc_flush_denormal_if_not_supported"....
19:49karolherbst: https://github.com/llvm/llvm-project/pull/207264
20:46robclark: karolherbst: ugg, so that sounds like needing to rebuild llvm? Or will you get the fix into f44?
20:49karolherbst: robclark: only rebuilding libclc
20:50karolherbst: robclark: I have a script: https://gist.github.com/karolherbst/73fd083651029e6aefcea62d6b384daf
20:50karolherbst: and then take the "libclc/build/spirv64-mesa3d-.spv" file
20:50karolherbst: that stuff will change with llvm-23 tho...
20:51robclark: thx.. ofc means we need to get it in debian/yocto for test team, etc.. sigh..
21:03karolherbst: robclark: yeah..... I mean I still think we should just include all of libclc and sync it often enough :D
21:03karolherbst: it's just a bit annoying to deal with patches
21:04karolherbst: I kinda want to make the sync easy, but then also have patches on top to fix random issues
21:43FireBurn: So I got bored trying to get vino to work, so I've re-created evdi in rust using the new bindings (plus a few extra) to test that all out
21:47FireBurn: Im hoping it'll behave better than evdi does, I fixed a few of its bugs and sent it upstream