01:53 Lynne: AndrewR: version 4 is *experimental*
06:25 valentine: looking into those CI issues, I think I see what's going on
07:01 dolphin: airlied, sima: could we get 6.15 backmerge to drm-next? I'd then gladly backmerge that to drm-intel-gt-next where build is breaking without on old GCC at the moment
07:05 sima: dolphin, you mean the gcc15 fixes from linus or something else?
07:07 dolphin: something else, build fails on Ubuntu 20.04 LTS I'm hearing
07:07 sima: hm those are in -rc4, so just backmerging drm-next should be enough since that's at -rc5
07:07 sima: dolphin, hm would need more details since Linus isn't a big fan of late backmerges
07:07 dolphin: let me check if it's already there
07:08 sima: quickly looking through the history didn't turn up anything obvious
07:08 sima: aside from gcc15 fix in -rc4
07:08 sima: unless I missed a later fix
07:08 dolphin: a67221b5eb8
07:09 sima: that's in -rc1 already?
07:09 sima: drm-next is -rc5 atm
07:09 dolphin: hmm, my impression was that -rc1 introduced the breakage
07:10 dolphin: I'll backmerge drm-next then.
07:10 sima: quick git log check didn't show any hit for Fixes: a67221b5eb8 or similar
07:11 sima: nor the commit summary
07:11 sima: I guess backmerging -rc5 isn't a bad idea anyway, so might as well do that
07:14 dolphin: hmm, dim backmerge seems to fail massively
07:15 dolphin: just spits out a long list of untracked files and exits...
07:57 AndrewR: Lynne, but then why it required with Vulkan encoder if it works without it with normal ffv1 encoder?
12:40 gio: Hi, while trying to run vkd3d tests on v3dv (using a Raspberry Pi 4B) I noticed that VK_KHR_shader_draw_parameters isn't available (and is required for vkd3d). Being quite clueless about that GPU (or, for that matter, any GPU) works, I was wondering: is there a fundamental reason why VK_KHR_shader_draw_parameters isn't offered? Or is it just a matter of nobody ever having cared
12:40 gio: enough about it?
12:41 gio: In other words, is that something somebody who doesn't know a lot about Mesa might figure out in their spare time, or is there some substantial work to be done?
13:17 alyssa: mareko: I'm looking at enabling the 16-bit caps for asahi (mostly out of curiousity), noticed something really problematic in shaderdb
13:17 alyssa: for reasons I don't fully understand, a bunch of shaders get store_output(undef) to non-existant render targets. ok, that all gets optimized out by nir_opt_undef, that's fine
13:18 alyssa: with the 16-bit i/o lowering, we first get instead store_output(f2f32(undef))
13:18 alyssa: nir_opt_undef turns that into store_output(nan) and suddenly a bunch of frag shaders go from 1 instruction to 20 because of a pile of NaN moves
13:19 alyssa: if I disable undef->nan optimization, later i/o lowering turns to store_output(f2fmp(f2f32(undef)) which folds to store_output(undef) and then gets deleted as it should be.
13:19 alyssa: Not really sure how to solve this properly though, there seems to be a bunch of layers of "sketchy" interacting
14:09 lumag: Current drm-tip fails to merge drm-xe-next, but I don't feel brave enough to handle that merge conflict.
14:09 lumag: jani: ^^
15:11 alyssa: no I mean fundamentally the way we have undef specced in NIR is a mess
15:11 mareko: and also branches with if (undef)
15:11 alyssa: (this is not new and it's not your fault)
15:11 alyssa: (and we all know this but also lol what do we do about it now)
15:13 mareko: I guess it's undefined whether undef means "undefined fixed value" or "anything goes"
15:13 alyssa: it's deeper than that
15:14 alyssa: but I don't really want to rehash that rn
15:14 alyssa: https://web.ist.utl.pt/nuno.lopes/pubs/undef-pldi17.pdf is the bible here
15:14 glehmann: spir-v's undef definition isn't more relaxed than NIR either
15:14 alyssa: (that papers about llvm but mesa likely has the same bugs)
15:16 demarchi: lumag: fixed
15:16 mareko: LLVM used to be far more broken than Mesa, basically any use of undef would result in the removal of most instructions using it, not replacing with a fixed value
15:17 alyssa: that I believe yea
15:18 alyssa: llvm's definitely more aggressive than we are
15:29 mareko: alyssa: I have no suggestion other than removing store([fui]2[fui]N(undef))
15:29 alyssa: wheee
15:29 alyssa: no worries
15:30 alyssa: i'm currently being grumpy about nir_lower_packing
16:01 alyssa: ..yeah this mess is too deep for me to think about anymore today, nvm
16:02 mareko: alyssa: is removing store(f2fN(undef)) not viable?
16:02 alyssa: mareko: it's not sound
16:02 alyssa: although my last comment was referencing nir_lower_pack
16:03 alyssa: i think that's my cue to crawl back into my cave for the morning
16:06 mareko: alyssa: what's the concern with the removal? we already remove store(undef), which is not less incorrect in theory
16:07 alyssa: mareko: if you load after a store(undef), it could be anything which matches what you'll load (which could also be anything)
16:08 alyssa: if you load after store(f2f32(undef)), it could only be a value that you could get out of f2f32, which is only about 0.0015% possible values
16:08 alyssa: statistically whatever garbage you load if you don't do the store is not in that <0.01% of possibilities
16:08 alyssa: so removing the store isn't sound
16:08 alyssa: (but replacing it with store nan as we do now is fine.)
16:09 mareko: removing store(undef) is also incorrect because the next load doesn't get the stored value
16:10 alyssa: ..so it is.
16:10 alyssa: wait, no that's fine
16:11 alyssa: store(undef) can be removed because whatever is currently in memory is perfectly good value of undef
16:11 mareko: x = undef; store(addr, x); .. then load(addr) == x must be true, no?
16:11 alyssa: only if undef is frozen, not Undef
16:12 alyssa: like i said. this is going in circles.
16:12 alyssa: i'm going to log off now.
16:12 mareko: ok
16:24 karolherbst: I think this entire undef business is something that the spirv WG has to decide or explicitly state, but I've heard they also don't know how to define undef, so... I think the only way to fix is, to make spir-v undef to be truly undef, add poison/freeze semantics to spirv, do the same for nir and then it's all explicit, but.. that's a bunch of work
16:24 karolherbst: :)
16:25 karolherbst: but yeah.. a true undef value doesn't compare to itself as equal, an undef out of a (undef % 1) can be any value, it doesn't have to adhere to the inherent characteristics of the operation. Like (undef * 2) & 1 doesn't have to be 0, it can be 1
16:26 karolherbst: but that all depends on how you define undef. If it's frozen by default, then the semantics are more strict
16:29 glehmann: the current spir-v spec reads to me like OpUndef can have different values per use, but something like undef & 0 is 0, not undef
16:30 pendingchaos: isn't the "(undef * 2) & 1" only for poison? I'm not sure if undef propagates like that
16:30 pendingchaos: though NIR also optimizes phi(undef)/mov(undef) to undef
16:30 karolherbst: my point was it depends on how you define it
16:30 karolherbst: which atm isn't defined at all
16:31 karolherbst: but I do think that spir-vs wording is close to "undef is frozen"
16:31 karolherbst: but not if you read the undef value a couple of times
16:31 karolherbst: it's not great
16:32 karolherbst: like yes you _could_ argue that "undef * 2" reads undef only once, but where is that written?
16:33 karolherbst: what if undef * 2 reads undef twice, and undef * 10 reads undef 10 times?
16:34 glehmann: it's not frozen, otherwise the spec would talk about "Each consumption"
16:34 karolherbst: it doesn't say what a consumption is
16:34 karolherbst: for all I know, opimul can consume each value 100 times
16:35 karolherbst: where is it stated that opcodes only consume each input exactly once?
16:35 glehmann: nowhere I guess, but it's clearly not frozen
16:36 cwabbott: I argued about this millenia ago and can confirm the intent was to match llvm's semantics at the time (i.e. not frozen)
16:36 karolherbst: fair
16:38 karolherbst: things are easier to argue on for like opcodes, but what if you pass a value as a function parameter? What if you need to lower the opcode to 100 instructions?
16:39 karolherbst: but anyway
16:39 karolherbst: should be clarified
16:57 mattst88: olivial: I think https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35196 is supposed to fix things
16:57 mattst88: pzanoni: ^
17:04 daniels: yeah, it is
17:04 daniels: so you can queue your MRs up now and they'll land after that
17:39 mattst88: cool, thanks
17:42 daniels: sorry about the breakage
18:05 mattst88: np. it happens, but we really appreciate the CI
18:05 mattst88: no doubt it's a massive net timesaver, even with hickups like this
18:08 olivial: nice, thanks for the fix :)
20:08 pzanoni: mattst88, daniels, valentine: thanks for the fix!