00:45 karolherbst: dcbaker: they are from https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32875 ?
00:45 karolherbst: ohhh... I see why they'd conflict
00:46 karolherbst: it's the changes in api/device.rs, right?
00:47 karolherbst: anyway, I don't think those fixes are critical enough to really bother much. They mostly just fix corner cases of the spec.
01:56 dcbaker: karolherbst: yeah, that's where the conflicts are
01:56 dcbaker: Okay, I can drop them and if they end up being important we can revisit if that works for you?
02:12 karolherbst: sure
03:23 Fya: Is there a reason why Intel's Windows drivers 60% faster at ray tracing? Is it just not optimized yet?
05:50 Kayden: Fya: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12346 looks to be highly relevant
05:50 Kayden: the common raytracing infrastructure used by both anv and radv is missing a fast past for TLAS updates
05:50 Kayden: *fast path
05:51 Kayden: the intel compiler backend in mesa has also been worse at register pressure, and raytracing tends to hit a lot of spilling
05:51 Kayden: though we've made a lot of strides with that recently
07:20 Fya: Kayden: I benchmarked with https://github.com/GPSnoopy/RayTracingInVulkan which /shouldn't/ have to update the TLAS as the scenes are static. So I suspect it is the compiler.
08:40 sima: dakr, did you see my question on provenance? it's really for my own learning, ever since kangrejos I'm trying to understand this better but it's really confusing for me
09:01 dakr: sima, no, is it on the mailing list, zulip, elsewhere?
09:01 sima: dakr, https://lore.kernel.org/rust-for-linux/Z36DU2Rf1O6cJbzG@phenom.ffwll.local/
09:02 dakr: Oh! Sorry, entirely missed that one.
09:27 dakr: sima, good question. And honestly, I'm not sure. The documentation defines provenance as "the permission to access an allocation’s sandbox". Without the Arc<> type in remove_action() we indeed may not have this permission.
09:28 dakr: As for why `DevresInner.devres_callback` is fine, I just assume because it's an FFI call, the compiler can't take assumptions on anyways.
09:30 sima: dakr, yeah my take is that the provenance we actually rely on comes in both cases from the Arc.into_raw -> Arc.from_raw guarantees
09:30 sima: and the provenance of the argument to remove_action does not matter, since all we use it for is as a bag of bits as a lookup key
09:31 sima: because the return value of devm_remove_action tells us that we now own this object and are allowed to call Arc.from_raw with that specific bag of bits
09:31 sima: so we don't need any other provenance that allows us to access this object
09:32 dakr: sima, I think it does matter, since we create the pointer out of thin air, the compiler can't track it back to the Arc::into_raw call.
09:32 sima: but the same applies to devm_callback?
09:32 sima: there it's even more out of thin air, entirely relying on Arc::from_raw guarantees
09:33 dakr: Yes, that's why I think the compiler doesn't put restrictions due to the FFI characteristic.
09:33 sima: yeah but why do those restrictions not apply to remove_action?
09:34 dakr: AFAIK, it's enough to break provenance if you take a pointer through Arc::from_raw convert it to an integer and convert it back.
09:34 sima: as a thought experiment: if instead of the raw pointer the lookup key that we pass to devm_remove_action_nowarn is an opaque cookie that we get from devm_add_action
09:35 sima: and devm_remove_action_nowarn then returns the raw pointer that we feed into Arc::from_raw
09:35 sima: it's semantically exactly the same stuff going on, except the lookup key and the raw pointer do not happen to have matching bits anymore
09:36 sima: this is why I think we don't care at all about the provenance of that reference, because we strictly only use it as a lookup key
09:36 dakr: Then I would expect it's fine, since we receive the pointer from an FFI call, and the compiler knows it can't take assumptions.
09:36 sima: not as a raw pointer, that raw pointer we get from devm_remove_action
09:37 sima: dakr, so if devm_add_action would simply return the raw pointer it used as lookup key, it would work?
09:37 dakr: devm_add_action?
09:37 sima: devm_remove_action
09:37 dakr: I guess so, yes. But I'm not sure.
09:38 sima: I thought the issue was that raw pointers do not have provenance, no matter what
09:38 sima: since they're just bag of bits
09:39 dakr: https://doc.rust-lang.org/std/ptr/index.html#provenance
09:39 sima: or put differently, the provenance of the reference that Arc::from_raw returns entirely relies on us correctly using Arc::into_raw, and not at all of any provenance the bag of bits we pass in happens to have?
09:40 dakr: AFAIU, it's one the raw pointer itself.
09:42 sima: so even if the raw pointer has provenance I think that should be deleted and replaced with the provenance guarantee of the into_raw -> from_raw sequence
09:43 sima: and if that doesn't happen, then I think into_raw -> from_raw is fundamentally busted
09:47 dakr: sima, I mean, you have a point. For FFI the documentation sounds broken, because you can't just fulfill the provenance requirement.
09:47 dakr: The the more I think about it, I don't think the compiler can detect it.
09:47 sima: yeah for ffi use-cases it works because the compiler cannot see behind the curtain
09:48 sima: "works"
09:49 dakr: sima, I mean, what if the devres callback would give me an integer instead of a pointer value, that we have to convert to a pointer in Rust? That would surely break provenance then. Would we need a C wrapper for this then?
09:51 sima: dakr, nah, just unsafe code which converts that integer value into an object reference, relying on compiler-nonvisible guarantees that we do have provenance for this stuff
09:51 sima: which is essentially why from_raw is unsafe
09:52 sima: or if that's not how into_raw and from_raw work, then we might need a into_bag_of_bits and from_bag_of_bits that handle this correctly
09:53 sima: from a compiler pov the into_raw->from_raw loop essentially works like free()->malloc()
09:53 sima: except the contents of the object stay the same
09:54 dakr: I don't think from_raw works this way, they're not special from the compiler side of things.
09:55 dakr: But reading your response on the mailing list, I feel like we may talk a bit past each other.
09:58 sima: dakr, how so?
10:00 sima: like the way I see it, the provenance chain is Arc::into_raw -> devm_add_action -> devm_remove_action_nowarn -> Arch::from_raw
10:00 sima: but we don't get a provenance back from devm_remove_action_nowarn, so it's busted
10:02 sima: and so my assumption was that provenance magically travels from into_raw to from_raw directly
10:05 sima: and if it doesn't, then into_raw/from_raw aren't magic enough for interacting with C functions
10:06 sima: they would be only enough magic for pointer packing tricks like in the strict provenance example in the rust doc page you've linked
10:16 dakr: There shouldn't be any magic in into_raw to from_raw, I implemented them for our kernel `Box` type.
10:16 dakr: sima, ^
10:17 dakr: It really should be on the raw pointer itself.
10:17 dakr: So, yeah, theoretically the FFI stuff might be broken.
10:18 sima: yeah, or at least we need something like creating a raw pointer from a bag of bits and a provenance we get from the ffi somehow
10:19 sima: so devm_remove_action_nowarn would return a provenance promise that applies for that specific bag of bits you've passed in
10:50 stsquad: did the mailing list archive just stop working at the end of '24 or are the lists just very quiet?
10:51 stsquad: I couldn't find an announce for 24.3.3 for example
12:47 alarumbe: tursulin: Hi, I posted a new revision with the changes you suggested for the format of drive-specific keys in fdinfo and also refacted drm_file.c a little bit and added a new helper for drivers
12:47 alarumbe: https://lore.kernel.org/dri-devel/20250108210259.647030-1-adrian.larumbe@collabora.com/T/#t
12:52 tursulin: alarumbe: Thanks for the ping! Something is wrong with my email setup and I did not see it until now.
14:24 alarumbe: tursulin: I've been thinking, maybe we should add a mention of a maximum key length to drm usage stats?
14:44 tursulin: alarumbe: I don't see that it would be a benefit. Userspace parsers can cope easier than we can emit crazy lengths from the kernel so I think it's okay to leave it open.
16:04 alyssa: :q
16:04 alyssa: oops
16:04 alyssa: (..you'll never guess what editor i use)
16:10 daniels: tzimmermann: I'd be wary of trying to ascribe too much structure and design to the English language :)
16:10 tzimmermann: :)
16:10 tzimmermann: yeah, i noticed that :D
16:10 daniels: it's a poorly-constructed language
16:11 daniels: (... of poor construction)
17:18 ManDay: Hi, I have a Gentoo problem: intel_clc does not accept LLVM-19; is that correct or is there actually a problem with LLVM-19 for intel_clc?
17:18 ManDay: (by a bunch of circular dependencies the above causes every clang and llvm in versions 18 and 19 to be installed, which seems excessive)
17:35 dj-death: ManDay: what do you mean by "does not accept"?
17:37 ManDay: dj-death: the definition of the package demands that intel_clc be compiled with llvm-18, rather than 19
17:37 ManDay: ( https://bugs.gentoo.org/947782 )
17:37 ManDay: Erm, I'm not even sure whether that's about compilation or usage
17:37 ManDay: Let me check that quickly
17:38 ManDay: my bad, it's usage/runtime
17:43 dj-death: that's not a mesa issue
17:44 dj-death: we just go with whatever LLVM is available as long as it's >= 15 if I remember correctly
17:46 Sachiel: maybe conflicting versions of llvm and spirv-llvm-translator?
17:47 dcbaker: daniels: English isn't a poorly constructed language, it's three poorly constructed languages standing on each other's shoulders all wearing a trench coat
17:48 alyssa: dcbaker: English doesn't exist https://www.babelio.com/livres/Cerquiglini-La-langue-anglaise-nexiste-pas-Cest-du-franca/1622524
17:49 dcbaker: Unless you can find me a Spanish (or classical Latin) translation I'm afraid I'll have to go on believing that English exists :)
17:49 daniels: dcbaker: :D
17:49 ManDay: dj-death: Well that is my question, whether intel_clc does have any specific requirements for the LLVM version
17:51 dj-death: ManDay: it does not
17:51 dj-death: ManDay: only LLVM-15+
17:52 ManDay: dj-death: thank you
18:49 alyssa:playing with printf format string compression
18:49 alyssa: zlib is very much not suitable for reasons i understand in retrospect
18:49 alyssa: but https://github.com/antirez/smaz/blob/master/smaz.c does ok
19:16 alyssa: karolherbst: jenatali: do either of you care about printf() performance in opencl?
19:16 jenatali: Nope
19:16 alyssa: (need to know whether I should hide my simple slow code behind an option so you guys can keep a complicated fast path)
19:18 alyssa: the idea is to just device-side write an entire serialized printf info into the printf buffer
19:18 alyssa: instead of just the index
19:18 alyssa: which gets rid of all the printf_info sidebands
19:19 jenatali: That does mean that the buffer would need to be much larger, wouldn't it?
19:22 alyssa: potentially yes
19:22 alyssa: for my use case that's probably fine, idk what apps do though
19:23 alyssa: the other idea I might try is serializing printf info into the shader constant data
19:23 alyssa: and then writing a gpu va
19:23 alyssa: that has... other issues though, lol
19:24 jenatali: FWIW I liked the hash map approach you mentioned
19:24 alyssa: that might be the winner then tbh
19:25 alyssa: gets 80% of the benefit with 20% of the stupidity.. yeah.. maybe let's do that
19:25 alyssa: thanks
19:25 alyssa: sometimes i get carried away
19:25 alyssa: and by sometimes i mean always
19:25 alyssa: and by carried away i mean i own a cape & wand
19:26 jenatali: Writing the format string would be useful if we wanted to support dynamically generated format strings in the shader, but CL doesn't allow that at least
19:26 alyssa: right
19:26 jenatali: I.e. CL's requirements were put in place specifically so you could avoid writing the format string into a buffer :)
19:26 alyssa: yes well when CL was specced they weren't intending it to be used to implement DGC :p
19:44 alyssa: hmm... I wonder if I can abuse __attribute__((constructor)) for this.....
19:45 alyssa: I think so. I like this....
19:46 alyssa: ("go back to sleep Alyssa")
19:47 alyssa: my annoyance with the hashmap approach is that the driver would need to call the "collect printf strings" from all the nir_builder things it might possibly use
19:47 alyssa: but i think i can abuse __attr__((constructor)) to collect all bindgen'd strings automatically without driver opt-in
19:48 alyssa: at which point the hashmap approach is strictly superior to dumping entire fmt strings in there
19:51 alyssa: jenatali: do we hate this?
19:53 jenatali: Seems fine to me I think. The one caveat of course being that attribute((constructor)) is GCC/Clang-specific. The only equivalent I'm aware of for MSVC is a global C++ class instance with a real constructor
19:54 jenatali: Or manually invoking it in DllMain but that's not going to work when you've just got a bunch of them
20:03 alyssa: oh, come on!
20:03 alyssa: of course msvc doesn't support this D:
20:05 alyssa: maybe I should swallow my pride, and vtn_bindgen should spit out c++ with real constructors
21:09 alyssa: OH: "They put the mesa MR merging lady in a tv show?"
21:11 kisak: <off-topic> https://tenor.com/view/marge-i-just-think-theyre-neat-the-simpsons-neat-potato-gif-8549864 </off-topic>
21:29 alyssa: kisak: that was the context, yes XD