11:11 FergusL: Hey there I ended up here from the mesa3d homepage. I'm a developer in a fairly distant field (DSP audio). The software I build depends statically or dynamically on llvm and I get hard segfaults when I run apps that make use of mesa/gallium, afaict the cause are symbol conflicts between my software's bundled llvm and the system one in /lib that
11:11 FergusL: gallium loads dynamically at runtime
13:00 FergusL: More generally, how the situation is handled when the same program wants to load 2 versions of llvm?
13:01 FergusL: I mean, the one that gallium loads that cannot be avoided afaict, plus one the developer needs for the program to run?
17:34 karolherbst: pray that you don't run into weirdo issues
17:35 karolherbst: in theory it shouldn't be an issue, but symbol resolving can be weird
17:35 karolherbst: FergusL: are you using glvnd or loading mesa directly?
18:26 FergusL: karolherbst I'm not doing anything myself, I ended up here after tracking the issue down but my stack is sdl2 with opengl3, I have no idea what it's doing
18:27 karolherbst: FergusL: it probably depends on your distribution then, but most moved to glvnd by now
18:27 karolherbst: I think there was some way to get around this issue by being smarter when dlopen the GL impl, but not quite sure
18:27 karolherbst: maybe the static linking messes things up
18:28 karolherbst: I did some testing with different LLVM versions and OpenCL driver loading, and I had llvm-15/16/17/18 all loaded in the same application and it worked fine... so not sure there is really that much we can do? Maybe we expose some LLVM symbols or the static linking causes some mess ups here, it's always hard to tell
18:29 FergusL: I tried with dynamic linking, it loads libllvm19 in /usr/lib and libgallium loads it from /lib/x86... Even though the files are identical. And I get roughly the same crash
18:29 FergusL: I suspect my Integrated AMD GPU might be the issue
18:29 FergusL: Back at my intel work laptop in a bit, mark my word, I bet it's going to just work
18:29 karolherbst: nah.. I've heard that users using different distributions ran into similar issues
18:29 tnt: karolherbst: Oh, it definitely doesn't always work nicely ... I need to make sure rusticl loads after intel-compute-runtime ( i.e. the order in which the ICD ae loaded ), or intel-compute-runtime breaks.
18:30 karolherbst: heh.....
18:30 karolherbst: that would imply that we might be doing something incorrectly..
18:30 karolherbst: or radeonsi is
18:31 FergusL: Honestly I would blame the software I'm using. I'm using the Faust dsp language, it has an llvm backend that dynamically recompile your DSP code
18:31 FergusL: The issue arises when I use this llvm backend and a gui app
19:24 airlied: FergusL: usually have to make sure symbol ber
19:24 airlied: versioning is turned on in any llvm builds
19:59 daniels: soreau: the ID is just a namespace; when it’s bound, Mesa looks up the ID -> object association in a hash table and stores that
20:00 daniels: you may very well be seeing some kind of bug, very possibly related to synchronisation, but it’s not down to the GL spec, and it’s very likely not down to Mesa’s implementation either tbh - note that Mesa did recently start reusing IDs of deleted names, which may trip up users who depend on ID equality to see if they need to rebind
20:57 Company: soreau: texture IDs work conceptually much like file descriptors do - it's a number for a resource that exists until you close()/glDelete() it and after that a new open()/glGen() can return that same number for a new object
20:58 Company: in fact, malloc() works the same way, only that it's not a literla number, but a void *
22:14 soreau: daniels: well I scrutinized the compositor code and it only binds once upfront, when the tex/fb id's are (uint32_t) -1, their inital value for the class. after the association is made, the only option is the destructor, which calls delete on the ids. from my printf debugging in the compositor and mesa, everything seems to check out.. if an id is handed out, it's not reused until after deletion
22:15 soreau: I do find it suspicious that so far, people are only complaining that it happens with wayfire and not other compositors using same version of wlroots
22:16 soreau: and once it starts happening, it's as if it gets stuck like this - moving a cursor over the main part of the toplevel might show a black square, while moving it to edge shows a good texture and then back to the 'normal' cursor for the toplevel it's black again
22:17 soreau: it really screams to me that the bug is in mesa but without a test case or another program that exhibits the same behavior, it's anyone's guess