01:59 zmike: hnnnnnnggggg few things feel better than a full-tree CI job passing on the first try
02:05 DavidHeidelberg[m]: :D I'm just hitting it with kernel testing.. I'm suprised it holding on
02:07 DavidHeidelberg[m]: but I think we'll have separate kernels ready to merge today. (so we can uprev kernel without rebuilding containers +- 10 minutes to rebuild + just the runtime of CI pipeline)
02:08 zmike: 🤑
02:09 DavidHeidelberg[m]: 🥳
02:40 DavidHeidelberg[m]: robertfoss: just saw object_management.alloc_callback_fail.device_group,Crash + two fails in multithreaded_per_thread_resources... on a618, weird flake, did I broke something on my branch (non freedreno related changes)? https://gitlab.freedesktop.org/mesa/mesa/-/jobs/44101480
07:55 cmarcelo: Vulkan Q: when an extension is promoted to core (e.g. vkCmdBeginRenderingKHR becomes vkCmdBeginRendering), should I still be able to vkGetInstanceProcAddr() of the extension one? trying to figure out if my scenario is a bug or just business as usual: when using 1.3 without enabling extension, it gives me invalid (but non NULL) pointer.
07:55 emersion: that sounds like a bug
07:58 cmarcelo: emersion: tks. so another Q: if app is using API 1.2 (before promotion) and enables extension and asks for the new non-prefixed symbol, should I also expect NULL? (my intuition would be yeah, beacuse is not in 1.2!)
07:58 cmarcelo: non-suffixed symbol
07:58 emersion: i wouldn't personally expect NULL, but don't quote me on that
07:59 emersion: if the ext is marked as supported by the driver, then it should just work
08:00 cmarcelo: right now I'm seeing 1.2+ext gets vkCmdBeginRenderingKHR = VALID, vkCmdBeginRendering = NON-NULL INVALID... and for 1.3 without explicitly enable, vkCmdBeginRenderingKHR = NON-NULL INVALID and vkCmdBeginRendering = VALID. 1.3+ext enabled, both valid.
08:02 emersion: can you make sure the ext is advertised by the driver?
08:04 cmarcelo: emersion: the ext is advertised by the driver.
09:44 karolherbst: I wished adding new system values wouldn't be so painful :'(
09:44 emersion: gfxstrand: can you check i'm not talking non-sense here? https://gitlab.freedesktop.org/mesa/drm/-/merge_requests/303#note_1967659
09:44 emersion: it's related to UMF
12:15 karolherbst: mareko: I'm trying to understand pipe_launch_grid::last_block, but radeonsi seems to behave a bit weirdly. So if I want to enqueue 513 threads, I'd split it up to block = { 512, 1, 1}, grid = { 2, 1, 1}, last_block = {1, 0, 0}, correct?
12:16 karolherbst: it kinda doesn't work as expected and I'm trying to figure out what's wrong
12:17 karolherbst: but maybe it's also more about system values not reporting the correct values than not running at all
12:17 karolherbst: but it's also that all relevant system values return 0, so not quite sure
12:18 karolherbst: I think it's more likely the last block doesn't run at all. But it does run when I set NUM_THREAD_PARTIAL to the block size
12:20 alyssa: where are my NIR_DEBUGs?!
12:21 alyssa: oh it sure would help if I were running my own build of mesa
12:23 alyssa: good work alyssa
12:24 karolherbst: ohh, the same thing happened to me today
12:24 karolherbst: wanted to test rusticl changes, but rusticl was disabled in my own build
12:25 alyssa: classic
12:30 HdkR: Need to get rusticl in that default build :)
12:33 dakr: mbrost: I submitted v5 of the GPUVA manager and the new Nouveau uAPI implementation yesterday. We're just about trying to get it in tree. Hence, your review is welcome. :)
13:16 karolherbst: jenatali: one thing which came up in some perf analysis, is that `clc_parse_spirv` can be quite expensive and I was wondering if you have caching code for `struct clc_parsed_spirv`
13:16 karolherbst: otherwise I or nora will probably add that to clc
13:21 jenatali: I don't think I do
13:22 jenatali: When I cache a compiled program I just return the SPIR-V and re-parse it on input
13:23 karolherbst: yeah.. same
13:23 karolherbst: but
13:23 karolherbst: jenatali: file:///home/kherbst/Downloads/with-patch.svg :')
13:23 karolherbst: ehh
13:23 karolherbst: wrong path
13:23 karolherbst: jenatali: https://cdn.discordapp.com/attachments/1033216738050969670/1121062852527128636/with-patch.svg
13:23 jenatali: Hah
13:24 karolherbst: clc_parse_spirv is a bit too expensive for my taste there
13:24 karolherbst: (also linking, but...)
13:25 jenatali: I personally wouldn't even consider that as an optimization target based on that, but I guess it can make sense
13:25 karolherbst: yeah... but we retrieve data from a cache anyway, so might as well retrieve the parsed info as well
13:26 jenatali: Fair
13:26 karolherbst: I suspect in this case the spirv is just massive in size
13:32 jenatali: It's a shame we can't let LLVM optimize before producing the SPIR-V
13:33 karolherbst: yeah.... though not sure if that gives us anything
13:33 karolherbst: we _could_ run some of the spirv-opt things
13:33 karolherbst: not sure how much they help though
13:34 karolherbst: I'd rather trust spirv-top than trust LLVM 🙃
13:34 karolherbst: *opt
13:34 jenatali: Yeah probably not much compared to letting it translate to nir
13:34 karolherbst: yeah...
13:34 jenatali: Letting LLVM optimize would shrink the SPIR-V quite a bit orobably
13:34 karolherbst: though it might reduce cacheing overhead
13:34 karolherbst: mhh
13:34 jenatali: But also produce odd size integers
13:35 karolherbst: yeah...
13:35 karolherbst: I think we'd need a list of safe LLVM passes to run
13:35 karolherbst: but..
13:35 karolherbst: I also don't trust LLVM
13:35 jenatali: Which is such a weird thing and it's a bit frustrating that the translator can't handle that and just upsize them
13:35 karolherbst: because it's illegal in spirv
13:36 jenatali: Sure but LLVM only produces odd size integers because it detected the value can fit in a smaller range. There's no harm in just using a bigger size
13:36 karolherbst: right...
13:37 karolherbst: I mean.. I think running LLVM optimizations is a fair thing to do, it just... difficult to ensure it doesn't generate stuff the translator can't handle
13:37 karolherbst: I'd rather have the translator pick passes it wants to make sure work
13:40 jenatali: What else can't it handle?
13:40 karolherbst: no idea at this point, maybe it works these days
13:42 gfxstrand: emersion: Not crazy. Thanks for the ping.
15:01 AndrewR: karolherbst, I think latest rusticl changes broke its compilation on 32-bit (missing gnu/stubs-64.h file)
15:02 karolherbst: uhhh....
15:02 karolherbst: annoying
15:03 karolherbst: yeah, I'll try to figure it out
15:03 karolherbst: do you have any logs?
15:03 AndrewR: I just update with git pull so it compiling anew ... partially.
15:03 AndrewR: will post if/when it stops again
15:07 AndrewR: ..or may be I just broke my llvm compilation by doing it without setarch first ..:/ (but then mesa not complained at automatic reconfigure. ..?)
15:47 mattst88: karolherbst: has there been any more progress on https://gitlab.freedesktop.org/mesa/mesa/-/issues/7717#note_1832122 ?
15:48 karolherbst: dcbaker: has there been any work towards supporting `#[cfg(test)]` stuff in a more meson way?
15:49 karolherbst: mattst88: no, but I might just go ahead and merge the patch and say: whenever CLANG_RESOURCE_DIR changes, rebuild mesa.
15:49 mattst88: even an environment variable for controlling CLANG_RESOURCE_DIR or something in Mesa would be a big improvement
15:49 mattst88: thanks. that would be fine with me
15:49 karolherbst: yeah.. it only affects gentoo I guess.. and I think other distribution can check whether that value ever changes or doesn't or whatever
15:50 karolherbst: and I think with llvm-16 they only hardcode the major version?
15:51 mattst88: yeah, in 15 it is
15:51 mattst88: 60:#define CLANG_RESOURCE_DIR "../../../../lib/clang/15.0.7"
15:51 mattst88: but in 16 it's
15:51 mattst88: 39:#define CLANG_RESOURCE_DIR "../../../../lib/clang/16"
15:51 karolherbst: yeah.. so in the future it isn't even a problem
15:52 mattst88: yeah
15:52 mattst88: I look forward to reviewing your MR :)
15:56 karolherbst: where was the patch again? :D
15:58 dcbaker: karolherbst: I think this affects nixos as eell
15:58 dcbaker: karolherbst: the only thing we have is the rust.test helper
16:01 mattst88: karolherbst: https://gitweb.gentoo.org/repo/gentoo.git/tree/media-libs/mesa/files/clang_resource_dir.patch is what we are using in Gentoo
16:02 karolherbst: yep, looks like the thing I suggested
16:02 karolherbst: (or somebody else)
16:08 mattst88: dcbaker: whenever you have time to make an MR for the intel_clc cross-compiling stuff, please cc me on it
16:10 dcbaker: mattst88: I’m looking into it now. It’s going to be a ton of typing, so I’m leaning toward making some meson changes to simplify the use case. I’ll send you the longer version when I’m not on my phone
16:11 mattst88: sounds good. thanks for your help on this
16:17 AndrewR: karolherbst, https://pastebin.com/8TdAtgWQ
16:17 AndrewR: karolherbst, but wait few hours until I recompile llvm again ...
16:17 karolherbst: yeah.. I kinda don't see how that could be our problem
16:18 karolherbst: `/usr/include/gnu/stubs.h:10:11: fatal error: 'gnu/stubs-64.h' file not found` it kinda tries to include a 64 bit header for a 32 bit thing? mhhh
16:18 karolherbst: mhhhh
16:19 AndrewR: it was working with llvm 16.0.5 then I hit wine bug with llvm going OOM ... so I upgraded, but it seems upgrade was a toast... I hardly can cook, even software!
16:19 karolherbst: yeah.. soo bindgen _could_ think it's compiling for 64 bit...
16:19 mattst88: that sounds like you're trying to build for an ABI that your toolchain doesn't support
16:19 karolherbst: not sure what's the proper way of dealing with this, but I think in the rust world you kinda assume everything is from the same toolchain
16:20 mattst88: are you on gentoo by chance?
16:21 mattst88: doesn't look like it from the build log
16:25 karolherbst: dcbaker: so the problem with rust.test is, that if you link against a C++ target you don't get automatically linked against libstdc++
16:26 karolherbst: any suggestions on how to resolve that?
16:28 AndrewR: mattst88, no, Slackware but with 64-bit kernel under i586 userspace. so apparently I just build clang crosscompiler by accident ...
16:28 mattst88: oh wow
16:28 karolherbst: I only have one question: how...
16:29 mattst88: my question is: do you really want opencl on 32-bit?
16:29 mattst88: and if so, I'm curious why
16:29 AndrewR: mattst88, well, ffmpeg supports it, so ...
16:29 karolherbst: I got a bug about a windows 32 app being broken with rusticl 🙃
16:29 LaserEyess: AndrewR: what... is your hardware
16:29 mattst88: I've left opencl disabled on 32-bit x86 in gentoo
16:30 AndrewR: LaserEyess, amd fx 4300, cre i3 somethng, aarch64 tablet
16:30 karolherbst: but anyway, it should build, but distributions might have to wiggle with the tooling a little
16:30 karolherbst: maybe we have to pass some flags along to bindgen? mhhh
16:30 LaserEyess: AndrewR: I mean for that specific machine with the i586 userspace because surely that's not running on aarch64...
16:30 karolherbst: is your rust tooling even for 32 bit?
16:31 AndrewR: karolherbst, last time I've rebuilt it - yes ...
16:31 karolherbst: funky
16:31 karolherbst: at least I didn't change anything in this regard
16:31 karolherbst: but clang invoked by bindgen kinda assumes it builds for 64 bit as it seems
16:31 karolherbst: but doesn't find the header files for it
16:32 AndrewR: karolherbst, yeah. I was trying to rebuild llvm and it complained clang does not know i586. Installed old 16.0.5 I build with setarch i686 - and build is running
16:33 AndrewR: LaserEyess, I've building for 'wide' set of machines because sometimes I visit friends with computers ...
16:34 LaserEyess: interesting
16:34 AndrewR: LaserEyess, for intel crocus/r600 testing I have this: https://pastebin.com/s857cYWT
16:36 LaserEyess: I am really glad people like you exist but at the same time I am glad I don't have to deal with this
16:36 LaserEyess: thank you for your service o7
16:36 AndrewR: :}
16:39 dcbaker: karolherbst: we should do that automatically in meson… does it matter if the c++ target is static or shared?
16:39 karolherbst: mhh not sure, we only link against static targets
16:39 karolherbst: so a meson bug most likely?
16:39 dcbaker: karolherbst: cool, I’ll try to have a look at that today too
16:41 karolherbst: mhh, let me verify something though
16:53 karolherbst: dcbaker: https://gist.githubusercontent.com/karolherbst/28d4edf3449063aa3671370147917d2b/raw/6a82e4f315b0654829d5ee958416403b4cd2f63b/gistfile1.txt
16:56 karolherbst: dcbaker: is there a quick and dirty hack to link against libstdc++ in a non silly way?
16:56 karolherbst: or rather.. how to create a dep object to it
16:56 dcbaker: Use cpp.find_library()
16:59 karolherbst: yeah.. that seems to work
17:00 karolherbst: but I run into another problem, mhh
17:16 karolherbst: yeah.. the other issues I can solve myself, just the libstdc++ thing is missed from mesons side
17:31 karolherbst: dcbaker: I think rust.test should also accept link_with or something, because now I just end up creating tons of declare_dependency objects
17:31 dcbaker: We can add that
17:32 karolherbst: also.. I can't add ideps with non rust source files, but I think that's expected and should be dealt with by projects
17:37 karolherbst: dcbaker: sooo.. with that I could make it work: https://gitlab.freedesktop.org/karolherbst/mesa/-/commit/bb7e7cd22423b9ec255f6ff39f6c2aadebaa7bb0
17:43 karolherbst: so yeah.. two problems, one critical: 1. doesn't link to libstdc++ automaticall, 2. rust.test should have a link_with so you can just link with random stuff
17:57 karolherbst: seems like I can move some things around to make it less painful, but I think it still good to have a link_with there
18:26 AndrewR: https://pastebin.com/0D6ucX40 - funny clpeak + clover on r600 crash in llvm 16 ...
18:57 alyssa: zmike: It looks like you accidentally pushed some other (unreviewed) commits to !23750, should marge be unassigned?
18:58 zmike: wtf
18:58 Sachiel: sneaky...
18:59 alyssa: Sachiel: https://www.youtube.com/watch?v=oLhLJDPToKc
19:03 karolherbst: `mold: error: duplicate symbol: src/gallium/drivers/radeonsi/libradeonsi.a(src/gallium/drivers/radeonsi/libradeonsi.a.p/gfx11_query.c.o): src/gallium/drivers/iris/libiris_per_hw_ver110.a(src/gallium/drivers/iris/libiris_per_hw_ver110.a.p/iris_query.c.o): gfx11_init_query` pain...
19:04 karolherbst: I'm sure that's my fault though :)
19:40 airlied: karolherbst: that seems like bug that LTO might fall over
19:40 karolherbst: potentially
19:41 karolherbst: but I think that might also be caused because I don't control what symbols to export in rusticl yet... but yeah...
19:42 karolherbst: but I still see tons of global symbols exported even after adding a linker-script
19:42 karolherbst: ehh version script
19:43 karolherbst: but if I'm not using `link_whole` then it drops the stuff I need
19:44 karolherbst: it's kinda weird
19:47 karolherbst: maybe I have to move some stuff into the target.c file I guess
19:47 airlied: seems like LTO wouldn't enjoy the collision
19:57 sassefa: Does anyone mind helping me with the my issue I posted above? Still really confused on what's going on w/ my system
20:00 karolherbst: ahh nevermind
20:00 karolherbst: thought there are still some weird symbols around
20:30 karolherbst: airlied: with that it's also resolved: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23778
20:30 karolherbst: but...
20:30 karolherbst: anybody who knows linking/exporting symbols stuff, please advise me on how to get rid of more symbols :D
20:37 jenatali: karolherbst: Those are imported, not exported
20:37 karolherbst: ohh... ehh
20:37 jenatali: UND == undefined, i.e. not defined in this module
20:37 karolherbst: how do I list exported symbols then
20:38 jenatali: There's so many tools that all do the same thing but slightly differently, I can never remember which one(s) I want or what switches :P
20:38 karolherbst: same
20:38 jenatali: I end up trying them all, between nm, readelf, objdump (I think?) I can never remember
20:38 karolherbst: I just want this tool which tells me what is exported...
20:39 jenatali: I like MSVC's, link /dump /exports and link /dump /imports
20:39 HdkR: karolherbst: Your only option on Linux is a linker script
20:39 HdkR: Which suuuuucks, but whatja gonna do
20:39 karolherbst: yeah, I already did that
20:39 karolherbst: and I still get more
20:39 jenatali: karolherbst: nm -D --defined-only ?
20:40 HdkR: Do you have a discard section in your linker script?
20:40 karolherbst: ahh!
20:40 karolherbst: defined-only works!
20:40 karolherbst: finally an answer!
20:40 jenatali: From the one non-Linux guy :P
20:40 HdkR: :D
20:40 karolherbst: still
20:40 karolherbst: there is too much
20:40 HdkR: karolherbst: https://github.com/FEX-Emu/FEX/blob/main/ThunkLibs/libVDSO/libVDSO_Guest.lds#L22 Example of the crap I had to go through
20:41 karolherbst: with cl it's simple
20:41 karolherbst: HdkR: https://gitlab.freedesktop.org/mesa/mesa/-/blob/eb192d39ac512005b0cdd854142e1691ef8747a4/src/gallium/targets/rusticl/rusticl.sym :P
20:41 karolherbst: that's it
20:41 jenatali: Huh. Dunno how you're getting typeinfos
20:41 HdkR: Time to slap it with some harder hammers
20:41 karolherbst: yeah.. same
20:42 karolherbst: but anyway.. if that's the entire list it's fine I guess
20:43 karolherbst: what does that "d" and "r" mean anyway
20:43 karolherbst: d: The symbol is in the initialized data section.
20:43 karolherbst: r: The symbol is in a read only data section.
20:44 karolherbst: oh well..
20:46 HdkR: Some of those upper things in mine are VDSO ELF exclusive so watch out :P
23:38 AndrewR: karolherbst, yeah, correctly-build (with setarch i686) llvm package fixed this error, sorry for falshe alarm