mehdi-djait3397165695212282475 has joined #dri-devel
LeviYun has joined #dri-devel
fab has joined #dri-devel
newyear25 has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
hawer has quit [Ping timeout: 480 seconds]
sima has joined #dri-devel
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
eukara has joined #dri-devel
LeviYun has joined #dri-devel
rgallaispou has quit [Read error: Connection reset by peer]
LeviYun has quit [Ping timeout: 480 seconds]
warpme has joined #dri-devel
LeviYun has joined #dri-devel
jkrzyszt has joined #dri-devel
<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
<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.
<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.
rgallaispou has joined #dri-devel
<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
<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
<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
<sima>
so we don't need any other provenance that allows us to access this object
<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.
<sima>
but the same applies to devm_callback?
<sima>
there it's even more out of thin air, entirely relying on Arc::from_raw guarantees
<dakr>
Yes, that's why I think the compiler doesn't put restrictions due to the FFI characteristic.
<sima>
yeah but why do those restrictions not apply to remove_action?
<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.
<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
<sima>
and devm_remove_action_nowarn then returns the raw pointer that we feed into Arc::from_raw
<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
LeviYun has joined #dri-devel
<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
<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.
<sima>
not as a raw pointer, that raw pointer we get from devm_remove_action
hansg has joined #dri-devel
<sima>
dakr, so if devm_add_action would simply return the raw pointer it used as lookup key, it would work?
<dakr>
devm_add_action?
<sima>
devm_remove_action
<dakr>
I guess so, yes. But I'm not sure.
<sima>
I thought the issue was that raw pointers do not have provenance, no matter what
<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?
<dakr>
AFAIU, it's one the raw pointer itself.
<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
<sima>
and if that doesn't happen, then I think into_raw -> from_raw is fundamentally busted
<dakr>
sima, I mean, you have a point. For FFI the documentation sounds broken, because you can't just fulfill the provenance requirement.
<dakr>
The the more I think about it, I don't think the compiler can detect it.
<sima>
yeah for ffi use-cases it works because the compiler cannot see behind the curtain
<sima>
"works"
<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?
<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
<sima>
which is essentially why from_raw is unsafe
<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
<sima>
from a compiler pov the into_raw->from_raw loop essentially works like free()->malloc()
<sima>
except the contents of the object stay the same
<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
<tursulin>
alarumbe: Thanks for the ping! Something is wrong with my email setup and I did not see it until now.
parthi has joined #dri-devel
itoral has quit [Remote host closed the connection]
jsa1 has joined #dri-devel
larunbe has joined #dri-devel
alarumbe has quit [Read error: Connection reset by peer]
parthi has quit [Remote host closed the connection]
parthiban has quit [Ping timeout: 480 seconds]
jsa1 has quit [Ping timeout: 480 seconds]
jsa1 has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
amarsh04 has joined #dri-devel
nerdopolis has joined #dri-devel
apinheiro has quit [Quit: Leaving]
The_Company has quit []
WhyNotHugo has joined #dri-devel
jfalempe has quit [Quit: jfalempe]
jfalempe has joined #dri-devel
bolson has joined #dri-devel
larunbe has quit []
glennk has quit [Quit: Leaving]
alarumbe has joined #dri-devel
glennk has joined #dri-devel
rgallaispou has quit [Read error: Connection reset by peer]
simon-perretta-img has joined #dri-devel
mvlad has joined #dri-devel
WhyNotHugo has quit [Remote host closed the connection]
WhyNotHugo has joined #dri-devel
alarumbe has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
vliaskov__ has quit [Ping timeout: 480 seconds]
fab has quit [Quit: fab]
fab has joined #dri-devel
nerdopolis has quit [Ping timeout: 480 seconds]
simon-perretta-img__ has quit [Ping timeout: 480 seconds]
Daanct12 has quit [Quit: WeeChat 4.4.4]
phasta has quit [Quit: Leaving]
alarumbe has joined #dri-devel
jsa1 has quit [Ping timeout: 480 seconds]
jsa1 has joined #dri-devel
<alarumbe>
tursulin: I've been thinking, maybe we should add a mention of a maximum key length to drm usage stats?
MrCooper has quit [Ping timeout: 480 seconds]
fab has quit [Quit: fab]
fab has joined #dri-devel
heat has joined #dri-devel
fab has quit [Ping timeout: 480 seconds]
MrCooper has joined #dri-devel
<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.
davispuh has joined #dri-devel
pH5 has quit [Ping timeout: 480 seconds]
shoragan has quit [Ping timeout: 480 seconds]
pixelcluster has quit []
kzd has joined #dri-devel
pixelcluster has joined #dri-devel
vliaskov__ has joined #dri-devel
fab has joined #dri-devel
jsa1 has quit [Ping timeout: 480 seconds]
dolphin has quit [Quit: Leaving]
jsa1 has joined #dri-devel
<alyssa>
:q
<alyssa>
oops
<alyssa>
(..you'll never guess what editor i use)
<daniels>
tzimmermann: I'd be wary of trying to ascribe too much structure and design to the English language :)
<tzimmermann>
:)
<tzimmermann>
yeah, i noticed that :D
<daniels>
it's a poorly-constructed language
<daniels>
(... of poor construction)
haaninjo has joined #dri-devel
bolson_ has joined #dri-devel
bolson has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
vliaskov__ has quit [Ping timeout: 480 seconds]
kaiwenjon has quit [Quit: WeeChat 3.8]
epoch101 has joined #dri-devel
kaiwenjon has joined #dri-devel
Duke`` has quit []
hansg has quit [Quit: Leaving]
jsa1 has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
mvlad is now known as Guest5427
Guest5427 has quit [Read error: Connection reset by peer]
mvlad has joined #dri-devel
tzimmermann has quit [Quit: Leaving]
jkrzyszt has quit [Ping timeout: 480 seconds]
Kayden has quit [Quit: -> JF]
ManDay has joined #dri-devel
<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?
<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)
larunbe has joined #dri-devel
sgruszka has quit [Quit: Leaving]
lynxeye has quit [Quit: Leaving.]
pixelcluster has quit [Quit: Goodbye!]
pixelcluster has joined #dri-devel
alarumbe has quit [Read error: No route to host]
Fya has quit [Ping timeout: 480 seconds]
Fya has joined #dri-devel
<dj-death>
ManDay: what do you mean by "does not accept"?
<ManDay>
dj-death: the definition of the package demands that intel_clc be compiled with llvm-18, rather than 19
<ManDay>
Erm, I'm not even sure whether that's about compilation or usage
<ManDay>
Let me check that quickly
<ManDay>
my bad, it's usage/runtime
Kayden has joined #dri-devel
<dj-death>
that's not a mesa issue
<dj-death>
we just go with whatever LLVM is available as long as it's >= 15 if I remember correctly
bolson has joined #dri-devel
mvlad is now known as Guest5431
Guest5431 has quit [Read error: Connection reset by peer]
mvlad has joined #dri-devel
bolson_ has quit [Ping timeout: 480 seconds]
<Sachiel>
maybe conflicting versions of llvm and spirv-llvm-translator?
<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
Guest5435 has quit [Read error: Connection reset by peer]
mvlad has joined #dri-devel
jsa1 has joined #dri-devel
oneforall2 has quit [Ping timeout: 480 seconds]
LeviYun has quit [Ping timeout: 480 seconds]
<alyssa>
karolherbst: jenatali: do either of you care about printf() performance in opencl?
<jenatali>
Nope
<alyssa>
(need to know whether I should hide my simple slow code behind an option so you guys can keep a complicated fast path)
mvlad has quit [Read error: Connection reset by peer]
mvlad has joined #dri-devel
<alyssa>
the idea is to just device-side write an entire serialized printf info into the printf buffer
<alyssa>
instead of just the index
<alyssa>
which gets rid of all the printf_info sidebands
<jenatali>
That does mean that the buffer would need to be much larger, wouldn't it?
<alyssa>
potentially yes
<alyssa>
for my use case that's probably fine, idk what apps do though
<alyssa>
the other idea I might try is serializing printf info into the shader constant data
<alyssa>
and then writing a gpu va
<alyssa>
that has... other issues though, lol
<jenatali>
FWIW I liked the hash map approach you mentioned
<alyssa>
that might be the winner then tbh
<alyssa>
gets 80% of the benefit with 20% of the stupidity.. yeah.. maybe let's do that
<alyssa>
thanks
<alyssa>
sometimes i get carried away
<alyssa>
and by sometimes i mean always
<alyssa>
and by carried away i mean i own a cape & wand
<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
<alyssa>
right
<jenatali>
I.e. CL's requirements were put in place specifically so you could avoid writing the format string into a buffer :)
<alyssa>
yes well when CL was specced they weren't intending it to be used to implement DGC :p
oneforall2 has joined #dri-devel
LeviYun has joined #dri-devel
ManDay has quit [Ping timeout: 480 seconds]
vliaskov__ has joined #dri-devel
<alyssa>
hmm... I wonder if I can abuse __attribute__((constructor)) for this.....
LeviYun has quit [Ping timeout: 480 seconds]
sima has quit [Remote host closed the connection]
<alyssa>
I think so. I like this....
<alyssa>
("go back to sleep Alyssa")
<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
<alyssa>
but i think i can abuse __attr__((constructor)) to collect all bindgen'd strings automatically without driver opt-in
<alyssa>
at which point the hashmap approach is strictly superior to dumping entire fmt strings in there
Duke`` has quit []
Duke`` has joined #dri-devel
<alyssa>
jenatali: do we hate this?
Duke`` has quit []
Duke`` has joined #dri-devel
Duke`` has quit []
Duke`` has joined #dri-devel
<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
mvlad has quit [Read error: Connection reset by peer]
mvlad has joined #dri-devel
<jenatali>
Or manually invoking it in DllMain but that's not going to work when you've just got a bunch of them
LeviYun has joined #dri-devel
<alyssa>
oh, come on!
<alyssa>
of course msvc doesn't support this D:
LeviYun has quit [Ping timeout: 480 seconds]
<alyssa>
maybe I should swallow my pride, and vtn_bindgen should spit out c++ with real constructors
rasterman has quit [Quit: Gettin' stinky!]
mvlad is now known as Guest5439
mvlad has joined #dri-devel
Guest5439 has quit [Read error: Connection reset by peer]
crabbedhaloablut has quit []
LeviYun has joined #dri-devel
gouchi has joined #dri-devel
mvlad is now known as Guest5441
Guest5441 has quit [Read error: Connection reset by peer]
mvlad has joined #dri-devel
mvlad has quit [Read error: Connection reset by peer]
mvlad has joined #dri-devel
mvlad has quit [Remote host closed the connection]
mvlad has joined #dri-devel
chomwitt has joined #dri-devel
anujp has quit [Ping timeout: 480 seconds]
<alyssa>
OH: "They put the mesa MR merging lady in a tv show?"