00:41 ndufresne: Company: rk3399 based board could be worth it, Intel 8K too
00:42 Company: ndufresne: I'm asking because mclasen has a branch going that does passthrough to the compositor, but to test how well it actually works and if it's worth it, we'd need an actual setup that benefits
00:43 Company: and neither mutter nor desktop hardware really care if you passthrough
00:43 ndufresne: What does it mean "they don't care?"
00:44 Company: your demo does run at 60fps with no noticeable CPU usage
00:44 Company: no matter if you passthrough or accidentally fallback to software rendering
00:44 ndufresne: With Weston or wlroot based compositor, HW layers will be used automatically, meaning you can go from codec to display without using the GPU
00:45 ndufresne: Try 4K60 fps ?
00:48 ndufresne: No GPU means the GPU can go to lower power state, and you get longer playback on battery, cooler system -> quieter experience
00:48 ndufresne: Well, that is for arm system, of course on PC your codec is in GPU
00:49 Company: if it actually is
00:49 Company: my codec is in vp9dec atm
00:49 Company: 89% cpu usage for a 4k video
00:51 Company: mplayer takes 45%, mpv 60%
00:55 ndufresne: Ah, so you are looking at dmanuf passthrough for software decode
00:58 ndufresne: Skipping GPU is one thing that comes to mind, but also avoiding forcing your compositor into Texture2D can help, the cpu load in such context should be the sum of app + compositor
00:59 Company: ndufresne: I'm looking at something that makes it visually obvious that passthrough doesn't work
01:00 Company: ndufresne: I want to see when it breaks
07:56 tzimmermann: javierm, hi! could you take a look at https://patchwork.freedesktop.org/patch/559767/?series=115715&rev=4 the patch fixes unloading of drivers with fbdev emulation
11:52 javierm: tzimmermann: the patch makes sense to me. Do you think that's worth to add a Fixes: commit c76f0f7cb546 ("drm: Begin an API for in-kernel clients") ?
11:54 tzimmermann: javierm, thanks for looking. i'd not bother about the fixes tag. the dependency handling now works correctly as the fbdev helpers depend on the driver module. maybe this wasn't the case in earlier releases
11:54 tzimmermann: and i only found that issue because i915 tests for unloading the driver module. no other driver seems to bother
11:55 tzimmermann: javierm, could you please send an ack to the list?
11:57 habernir: anyone know what happen to mesa version 23.2.2?
11:57 habernir: or everything is ok with dylan baker
11:57 habernir: ?
12:01 javierm: tzimmermann: done
12:01 tzimmermann: javierm, thank you
12:03 tzimmermann: javierm, there's something else to ask you. that work on fbdev init helpers and macros is comming to an end. i only have various patches left that implement this and that. shall i post them in one big series?
12:12 javierm: tzimmermann: sure, that works for me. I'll probably won't have time to do any review until Friday though
12:12 tzimmermann: no worries :)
14:33 gfxstrand: dcbaker: FYI: My goal for this week is to land NAK.
14:34 gfxstrand: dcbaker: I'm working on figuring out how to hack around the 32-bit problems. I'm experimenting with marking things native in the wraps I pull in (they're only used for proc macro build deps) but still having issues where it can't find built-in creates like core::
15:39 bl4ckb0ne: is there something specific to do to get the MESA prefix for an EGL ext beside producing the impl?
15:39 emersion: need to reserve in khronos
15:40 emersion: and merge the API there as well I think
16:14 gfxstrand: Anyone feeling brave and want to review a nir_lower_io MR?
16:14 gfxstrand:
16:14 gfxstrand: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25916
16:15 karolherbst: oh shit.. that reminds me
16:15 karolherbst: thanks for reminding me
16:15 gfxstrand: I don't strictly need it for NAK but I do need some of it to pass CTS.
16:16 gfxstrand: I also suspsect other drivers will want it as well. AMD, maybe?
16:40 dcbaker: gfxstrand: sweet! the can't find core thing is interesting, same branch or a different one? I'll see if I can poke at it a bit and help
16:45 gfxstrand: dcbaker: Let me dig around. IDK that it's in a branch yet.
17:08 gfxstrand: dcbaker: nak/native-wrap in my gitlab
18:07 airlied: gfxstrand: btw is it wednesday, pinging about the llvm17 blocker :-)
18:07 gfxstrand: airlied: Right. Thanks.
18:07 gfxstrand: I'll take a look at that while dcbaker is poking at meson
18:07 tango_: hello all, I'm getting a kernel NULL pointer dereference on a thinkpad P15v gen3 amd when I enable both the mesa Clover ICD and the amd rocm (5.7.0) one. no issues if both rocm and rusticl are enabled, or with clover and rusticl. the fault seems to be specifically on clover+rocm. should I file this against mesa, rocm or both?
18:08 tango_: it's not a showstopper for me because clover can't actually use the gpu anyway for compute, but I thought it might be useful to know that there is this issue
18:09 gfxstrand: IDK that I particularly trust either driver but I guess file something against clover for now.
18:09 gfxstrand: Can't promise how quickly someone will look into it but we may as well have it written down.
18:10 gfxstrand: airlied: I'm gonna have to install LLVM 17 aren't I?...
18:12 airlied: gfxstrand: not sure if you can easily grab bits from f39
18:12 gfxstrand: Is it in f39 or rawhide?
18:12 gfxstrand: I'm going to try pulling from rawhide
18:12 airlied: or use an f39 vm
18:12 airlied: pretty sure f39 has it
18:20 gfxstrand: airlied: Nah, highest I can get from either is an llvm16 package.
18:22 gfxstrand: Looks like there's a copr
18:22 airlied: llvm in f39 should be 17
18:22 airlied: llvm16 is the compat package
18:23 gfxstrand: Oh...
18:23 gfxstrand: Why do they not just all have versions?!? *sigh*
18:23 gfxstrand: Okay, let's install from f39 and hope it doesn't break
18:28 gfxstrand: Yikes! It wants to update glibc... That's not gonna be good.
18:28 gfxstrand: Maybe I should just update to f39 beta today?
18:29 daniels: it mostly works these days
18:30 gfxstrand: Yeah, I'm usually not too worried about Fedora betas
18:30 gfxstrand: I'm slightly more worried about installing a glibc from fedora N+1 without doing an actual upgrade. (-:
18:48 airlied: gfxstrand: I did the glibc update yesterday on my f38 and it seems fine
18:48 airlied: and I did it just for vulkan-loader :-P
18:54 Company: can confirm that F39 works fine
18:54 Company: I updated a week or 2 ago and haven't had any issues
19:02 tango_: gfxstrand: FWIW, the issue is here https://gitlab.freedesktop.org/mesa/mesa/-/issues/10078
19:02 tango_: now that I think about it, it might make more sense to report it as a kernel issue
19:05 tango_: (is there a way to move or cross-post an issue in gitlab to a different project, drm/amd probably in this case?)
19:07 gfxstrand: tango_: It's okay. I moved it
19:07 gfxstrand: airlied: Too late. Now running F39.
19:18 alyssa: crab fire.jpg
19:26 DemiMarie: gfxstrand: why would it be a bug in Clover? Kernel NULL pointer dereference is always a kernel bug, right?
19:27 gfxstrand: DemiMarie: The word "kernel" gets overloaded and I didn't know if he they were talking about kernel kernel or a GPU kernel. (-:
19:27 gfxstrand: Why, CL, why?!? *sigh*
19:27 karolherbst: yo
19:27 karolherbst: whatever the problem is, I agree
19:29 gfxstrand: crab_fire.jpg
19:30 alyssa: if both NAK and CL extravaganza land this week
19:30 alyssa: that will be deserving of crab_fire.jpg
19:30 karolherbst: mesa v2
19:30 gfxstrand: lol
19:31 DemiMarie: gfxstrand: from my PoV, a NULL pointer dereference in a GPU kernel is no big deal, while a Linux kernel NULL pointer dereference could indicate something more serious (like exploitable kernel memory corruption that happened to first cause a NULL pointer dereference).
19:31 DemiMarie: So my assumption was that this was the more serious kind.
19:32 DemiMarie:wonders if Mesa should have LLVM as a git submodule
19:32 karolherbst: no
19:32 jenatali: No
19:33 karolherbst: worst case we just fail to compile with llvm-17 and newer and make everybody elses life miserable
19:34 alyssa: i should maybe do my day job.
19:34 Sachiel: nah
19:35 Sachiel: it's almost friday, not worth starting now
19:35 alyssa: very true
19:35 karolherbst: I had the last two days of and worked on zink on nvidia stuff, maybe I just stop working this week :D
19:37 jenatali: Since when is Wednesday "almost Friday"?
19:38 alyssa: jenatali: since 12:01pm
19:38 jenatali: :P
19:38 alyssa: unless you take fridays off
19:38 alyssa: then Tuesday night
19:38 gfxstrand: It is after noon. Therefore, it rounds up to friday.
19:38 alyssa: yes
19:38 gfxstrand: Otherwise, it would have been still mostly monday
19:38 alyssa: yep
20:08 gfxstrand: I knew making paths handle casts was going to bite us...
20:09 jenatali: Hm?
20:09 gfxstrand: Oh, looking at these LLVM fails and we're failing because of the way that nir_deref_path just silently ignores trivial casts.
20:10 jenatali: :(
20:10 airlied: gfxstrand: so we should push my fix and ignore the biting for longer :-P
20:10 gfxstrand: airlied: Annoyingly, I may be coming to that conclusion. :P
20:11 alyssa: chomp
20:11 gfxstrand: airlied: Well, not quite. Need to make one tweak to your patch.
20:12 karolherbst: maybe I should test with llvm-17.. :D
20:12 karolherbst: but I also wanted to look into the native spirv backend stuff...
20:15 alyssa: chomp
20:15 jenatali: gfxstrand: I'm looking at VK_LUNARG_direct_driver_loading, and its implications on vk_icdGetInstanceProcAddr, which starts to allow getting the vk_icd* functions instead of exports from the .so/.dll with loader interface v7. Given that there's like 3 entrypoints, I think it's not worth trying to do a codegen solution to share among the drivers. Thoughts?
20:19 jenatali: Since they're not in the VK .xml API definitions...
20:19 gfxstrand: jenatali: Hrm...
20:19 gfxstrand: jenatali: I think at the very least we need to be able to return *something* from *GetInstanceProcAddr
20:20 jenatali: Right now, each driver implements their own vk_icdGetInstanceProcAddr as a wrapper around the common version
20:20 jenatali: For loader iface v7, that is now allowed/suggested to start returning success for ICD entrypoints in addition to API instance entrypoints
20:21 jenatali: But those entrypoints aren't in the XML since they're not part of the API, just part of the ICD/loader interface
20:22 jenatali: So, my question is should I write a little bit of code in dzn to support iface v7, or should I try to do something fancy so we can get a one-liner (or few-liner) in any driver that wants iface v7
20:22 gfxstrand: So I think the only fancy thing we would need to do is to add 2-3 special cases to the common get_instance_proc_addr impl.
20:23 gfxstrand: IDK that we need codegen for it
20:23 gfxstrand: We can just have a couple strcmp or something
20:23 jenatali: Except each driver has their own implemention of the ICD entrypoints too
20:23 jenatali: Manually written out instead of codegen'd
20:23 gfxstrand: Those *should* just be one-line wrappers to make sure they get exposed as symbols.
20:24 gfxstrand: If they're doing anything functional in there, that's sketchy
20:24 jenatali: Well, the version negotiation one is a one-liner impl instead of wrapper, but yeah
20:24 gfxstrand: Hrm... I see what you mean, I think.
20:24 gfxstrand: Well, maybe not?
20:24 jenatali: And enumerating devices, the helper is optional
20:25 gfxstrand: Right, the version negotiation one is the one that I wonder about
20:26 gfxstrand: Though, honestly, does anyone have a good reason to do their own thing there?
20:26 gfxstrand: I kinda think no
20:26 jenatali: Yeah probably not
20:27 gfxstrand: Ugh... This is all very annoying
20:28 jenatali: Yeah. The nice thing is that it means I don't need to add vk_icdEnumerateAdapterPhysicalDevices to lavapipe's .def file
20:28 gfxstrand: So the one thing that does need to be unique per-driver is driver_GetInstanceProcAddr() because that has to point at the instance entrypoint table.
20:28 jenatali: Right
20:29 gfxstrand: And maybe vk_icdGetInstanceProcAddr() because it needs to call that
20:29 gfxstrand: But that's just a one-liner
20:30 gfxstrand: We can special-case "vk_icdGetInstanceProcAddr()" inside of instance_proc_addr to point to the driver one. That's easy enough.
20:31 gfxstrand: jenatali: So I think the answer to your broad quesiton of "should we fix this" is yes. The details are a mess but, yes, we should fix it.
20:31 jenatali: Cool
20:32 jenatali: Looks like pvr and nvk still report ICD iface v4, the rest of the tree is v5
20:32 jenatali: That should really just be de-duped
20:32 gfxstrand: Yup
20:35 jenatali: Ok, so I'll de-dupe that and vk_icdGetPhysicalDeviceProcAddr, neither of those should be unique
20:35 gfxstrand: yup
20:35 gfxstrand: NVK doesn't have a good reason. Just that I didn't want to think about v5 yet.
20:35 gfxstrand: I guarantee PVR doesn't have a good reason. :-P
20:36 jenatali: Great. I definitely started that discussion without thinking it all the way through (still in the process of ramping back up after 12 weeks not thinking about code)
20:36 jenatali: And then I'll figure out what to do with vk_icdEnumerateAdapterPhysicalDevices, which is the whole reason I care right now
20:38 gfxstrand: Yeah, that one's annoying.
20:38 gfxstrand: Silly windows...
20:39 jenatali: Yeah. But hey, with v7 at least it doesn't need to be exported from the DLL anymore, which means I don't need to have different .def files for lvp and dzn
20:39 gfxstrand: airlied: Want to look at the LLVM 17 MR. I just beefed the patch up a bit.
20:39 gfxstrand: Oh, and let me add a fixes tag
20:39 jenatali: I still need to do something to prevent lvp from exposing that function though but at least I can do it in code instead of at build time
20:45 gfxstrand: airlied: I mostly just made it not throw away alignment informaiton. No idea if that will ever matter for anything (probably not) but wanted to be sure.
20:45 airlied: gfxstrand: looks good to me
20:45 jenatali: Ugh. Venus
21:03 gfxstrand: alyssa: CLC stuff looks pretty good. I left some comments but they're all cosmetic.
21:03 gfxstrand: Delightfully cursed is how I think I'd describe that MR. :joy:
21:07 jenatali: Good description
21:08 gfxstrand: I just want it for all of NIR. :D
21:09 gfxstrand: Okay, now back to seeing if I can get NAK to build 32-bit
21:10 gfxstrand: Ooh, nice! I can drop my DivCeil impl from NAK and use the thing in Rust 1.73
21:10 gfxstrand: Looks like NAK is going to require 1.73
21:13 alyssa: gfxstrand: thanks!
21:16 alyssa: gfxstrand: thanks!
21:19 karolherbst: gfxstrand: ohhh.. that stuff lands in 1.73? cool
21:19 gfxstrand: Yeah, and it's badly needed.
21:22 alyssa: gfxstrand: Addressed the cosmetic things, want to give one last look or shall I assign to karol?
21:22 alyssa: ("Don't you mean Marge?" "o:)")
21:22 alyssa: :P
21:22 alyssa: karolherbst: ;P
21:23 karolherbst: do it
21:23 karolherbst: I can bounce it back if you want
21:24 alyssa: >:)
21:24 gfxstrand: alyssa: There we go. Gave you an RB
21:25 alyssa: blahaj_grinning.jpg
21:25 alyssa: + /* TODO: Can we recover parameter names? */
21:25 alyssa: do either of you know?
21:25 gfxstrand: Can we? Yeah, probably. Is it worth the effort? Probably not.
21:25 alyssa: mood
21:26 gfxstrand: And if we do then we have to deal with the case where some jerk writes my_helper(arg0, arg2, arg1) just to mess with us
21:26 alyssa: The use case is if you use an IDE (or youcompleteme or whatever) and it'll pop up the function signature, even if the func is defined in autogenerated .h
21:26 alyssa: (currently I need to open the original .cl to get the names when calling from .c)
21:30 alyssa: aside: with my [redacted] branch, I'm writing greenfield NIR passes with clc from the start and WOW is it faster!
21:35 karolherbst: alyssa: declare those functions in a header file or something, on the GPU side they evaluate to the function call, on the CPU side they just wrap around the nir_build_call thing
21:35 karolherbst: but yeah...
21:35 karolherbst: more work or something
21:36 alyssa: karolherbst: not needing to type .h manually is a feature heh
21:37 gfxstrand: I'm tempted to use it NVK just for query copies
21:37 gfxstrand: dcbaker: It appears that the rust_args from my cross file aren't making their way through.
21:38 alyssa: gfxstrand: >:)
21:39 karolherbst: so we replace all of nir_builder now or what :P
21:39 gfxstrand: Maybe not all
21:39 gfxstrand: One of the as-yet unsolved problems is calling NIR intrinsics but I've got a half a plan for that.
21:40 jenatali: I'll say that making clc a core requirement of nir will make the barrier to entry on Windows incredibly high
21:41 gfxstrand: Oh?
21:41 gfxstrand: I mean, yeah, LLVM sucks.
21:41 karolherbst: gfxstrand: I actually wonder how painful that would be... but in the end we can just have some internal header with all the intrinsics and resolve it inside vtn
21:41 jenatali: Windows doesn't have distros that produce libraries you can link against. You have to compile it yourself
21:41 gfxstrand: We have a wrap...
21:41 alyssa: jenatali: ...what about clon12
21:41 jenatali: Do we?
21:42 jenatali: alyssa: Yes, the barrier to setting up a build for that is enormous
21:42 gfxstrand: Oh, I thought we did.
21:42 alyssa: jenatali: Oof.
21:42 gfxstrand: I guess not
21:42 karolherbst: llvm build system moment right there
21:42 jenatali: Obviously it's not my call at the end of the day, just wanted to say it'd be painful for me
21:43 gfxstrand: Yeah, I think it would be painful in any non-Linux, TBH.
21:43 gfxstrand: And I'm a little worried about stuff like the LLVM17 issue we just had
21:43 karolherbst: just download llvm.dll
21:43 Sachiel: what's this about?
21:43 karolherbst: yeah...
21:43 gfxstrand: It would be one thing if we were baking in SPIR-V and could just invoke a recent enough verion of clang.
21:43 karolherbst: LLVM is a pain
21:44 karolherbst: but look
21:44 karolherbst: we already know the answer
21:44 gfxstrand: A lot of the SPIR-V bloat is because we have to -O0 it but with recent LLVM we *should* be able to build to SPIR-V with -O3
21:44 karolherbst: the question is
21:44 karolherbst: who is gonna write that code
21:44 jenatali: Yeah if the process for producing the SPIR-V was to invoke prebuilt tools via the build system, I'm all for that. But right now it requires linking custom code against LLVM libs, and that's really bad on Windows
21:45 jenatali: You can download clang.exe, but there's no clang.lib
21:45 karolherbst: pain
21:45 karolherbst: guess we have to write a CL C parser for mesa then...
21:45 alyssa: jenatali: I think the real sol'n will be to switch to llvm's spirv backend
21:45 gfxstrand: I think the first step here is to play with the new SPIR-V back-end in LLVM
21:45 gfxstrand: jinkx!
21:45 gfxstrand: jinx
21:45 karolherbst: but yeah..
21:45 karolherbst: that already helps a lot
21:45 alyssa: and then be able to do clang.exe at buildtime instead of linking.
21:45 jenatali: Yeah, removing that translator dep will definitely help
21:46 i509vcb: I thought all the rage these days was rust -> spriv with llvm
21:46 alyssa: crab_angel.jpg
21:47 gfxstrand: But yeah, if we can just invoke clang with -march=spirv64, that'll help a lot
21:47 i509vcb: NAK does make that agxv in rust idea quite tempting assuming it doesn't result in hell...
21:51 karolherbst: who does want to look into native spirv backend stuff though? Or should I just plan that for myself for like... next week or something
21:52 alyssa: thx for volunteering
21:52 alyssa: ;)
21:52 karolherbst: yeah, np
21:52 karolherbst: I think I already kinda said I'd do it
21:52 jenatali: karolherbst: I'm interested, but won't have time for a little while
21:53 karolherbst: the curse of our times
21:53 karolherbst: *time
21:53 karolherbst: but I also want to get rusticl conformant on vulkan sooo....
21:54 airlied: I'd just stick to rusticl conformance, the spirv backend is likely going to be a bit of a timesink
21:54 karolherbst: yeah, same
21:54 karolherbst: but also nvidia is bothering me
21:54 gfxstrand: IDK... The translator bugs are also a timesink
21:54 airlied: you think the backend is going to be better? :-)
21:55 karolherbst: and not sure if I get away with anv + radv as the impls :D
21:55 karolherbst: if I look at the bugs intels SyCL impls has....
21:55 karolherbst: then uhhh
21:55 airlied: karolherbst: I'd back anv and radv as separate implementations :-P but I could see why khronos might not
21:55 karolherbst: it's worse
21:55 karolherbst: airlied: yeah... same
21:55 karolherbst: hence I've asked
21:55 karolherbst: but I have a complete run on radv, so there is that
21:56 gfxstrand: Long-term the back-end will definitely be better.
21:56 gfxstrand: IDK if it's better right now.
21:56 karolherbst: yeah..
21:56 karolherbst: we might want to wait until llvm-18 anyway
21:56 airlied: getting nvidia bugs fixed will be probably a bit of a blocker though
21:56 karolherbst: yeah.....
21:56 gfxstrand: According to various folks, it's passing CTS on top of the Intel proprietary driver.
21:56 karolherbst: I mean...
21:56 karolherbst: yes
21:56 karolherbst: but they also eat invalid spir-v
21:56 karolherbst: I've filed a lot of bugs
21:57 karolherbst: and the SyCL spir-vs they generate trip over vtn a lot, because it's invalid
21:57 karolherbst: like..
21:57 jenatali: Yeah I've seen that too
21:57 karolherbst: builtins in CrossWorkgroup ...
21:57 karolherbst: and other random nonsense
21:57 gfxstrand: Ugh... I'm running into meson --edition bugs, I think.
21:58 jenatali: +128 −733, nice
21:58 karolherbst: anyway.. I'll probably look into it if nobody else does
21:58 karolherbst: I think it's easy to flip over
21:59 karolherbst: and the CTS will tell me what burns
21:59 karolherbst: could have it as an env var for testing for now
21:59 gfxstrand: Yeah, I think that's the first step
21:59 gfxstrand: Have an ENV var or some other easy switch and then folks can help figure out the bugs
21:59 karolherbst: yep
21:59 karolherbst: the issue is.. some clang versions invoke the llvm-spirv binary instead
21:59 gfxstrand: I did nicely tell the people working on it that if it doesn't pass SPIR-V validation, I don't really care that the Intel driver is happy.
22:00 karolherbst: so I also have to figure that part out
22:00 karolherbst: gfxstrand: yeah...
22:00 karolherbst: I mean
22:00 karolherbst: in rusticl I don't verify internal spir-vs because....
22:00 karolherbst: _but_
22:00 karolherbst: my runs with offline compiled spir-vs have like 2 fails more
22:00 karolherbst: and I do validate all external spir-v
22:01 karolherbst: and I know for a reason that intels' CL impl doesn't
22:01 karolherbst: those are the current issues I've filed against intel/llvm https://github.com/intel/llvm/issues/created_by/@me
22:02 karolherbst: ehh
22:02 karolherbst: https://github.com/intel/llvm/issues/created_by/@karolherbst
22:02 karolherbst: ehh wait
22:02 karolherbst: that doesn't work
22:02 karolherbst: pain
22:02 karolherbst: https://github.com/intel/llvm/issues/created_by/karolherbst
22:02 karolherbst: not sure how many of those are upstream llvm bugs
22:04 jenatali: gfxstrand: Are you still the person to ask for Vulkan runtime reviews?
22:05 jenatali: If so, !25998 pretty please :)
22:23 gfxstrand: dcbaker: I have a theory as to why it's not working. Meson isn't passing rust_std through from parent project to subproject.
22:24 gfxstrand: Which is fine right up until you do a cross build at which point something somewhere along the line zeros out rust_std
22:27 gfxstrand: dcbaker: Hrm... I think the real problem is that --edition really shouldn't be per-machine
22:29 gfxstrand: dcbaker: Yeah, that's the problem.
22:30 gfxstrand: Well, rust_std is generally handled wrong
22:31 gfxstrand: rust_std should be per-crate and generally not per-machine
22:32 gfxstrand: dcbaker: I can hack around it sort-of with --native-file except that I want 2021 for NAK and proc-macro2 wants 2018 and breaks with 2021
22:39 dcbaker: gfxstrand: sigh. Yeah, we have always basically assumed that things would be backwards compatible or that you would never cross a breaking boundary (ie, c++98 vs c++11). I think you can work around this issue by adding `override_options : ["rust_std=2018"]` to the library call that creates the proc-macro itself
22:40 gfxstrand: dcbaker: The problem is that rust_std and c++_std are not at all the same thing
22:40 gfxstrand: Rust editions are DESIGNED to allow linking across editions.
22:41 gfxstrand: C++ editions much less so
22:41 dcbaker: Really C++ is kinda special in that it doesn't necessarily allow linking across standards. C and Fortran do
22:41 gfxstrand: But, yeah, if meson is trying to handle rust_std like it's handling c++_std, then one or both are going to be broken.
22:42 dcbaker: But C++ is like rust in that things probably don't compile with the wrong version
22:42 dcbaker: it's really that it's treating everything like C, where everything is always 100% forward compatibile
22:42 dcbaker: s/it's/meson
22:42 gfxstrand: So it's all wrong! :joy:
22:42 dcbaker: and it's a known issue that I've been arguing we should fix for a long time :/
22:43 dcbaker: I think Xavier has done some work to try to make that happen
22:43 gfxstrand: Is there a chat where I can get both you and Xavier?
22:43 gfxstrand: Should I just join #meson?
22:43 gfxstrand: Please don't say the answer is Matrix
22:44 dcbaker: We have a bridged channel between matrix and oftc
22:44 mattst88: #mesonbuild :)
22:44 dcbaker: I can't remember if it's #meson or #mesonbuild:matrix.org
22:44 dcbaker: but yes, Xavier and I are both there, and so are a couple of other people interested in Meson + Rust
22:44 gfxstrand: Okay, I'll bother both of you there more tomorrow
22:45 gfxstrand: I have enough hacks piled up to know where the bugs are at this point.
22:45 dcbaker: sounds good
22:45 gfxstrand: dcbaker: The other bug I'm hitting is that meson is trying to link in my proc macro because it's a dependency.
22:45 gfxstrand: But that blows up because it's x86_64 and the lib I'm building is x86_64
22:45 gfxstrand: *lib I'm building is i686
22:45 dcbaker: That is a known issue. I can't remember if anyone volunteered to look at it.
22:46 dcbaker: along with about a million other corners of dependency
22:46 dcbaker: If no one else is I can look at taht
22:46 gfxstrand: dcbaker: The question I'm asking myself is what should I wait to be fixed before I land NAK.
22:47 gfxstrand: I'm tempted to just land it and say "Sorry, cross builds broken with NVK. It'll get fixed one day."
22:47 gfxstrand: I really don't like that but we're getting to the point where NAK being in a branch is getting painful.
22:47 dcbaker: Xavier and I have been talking about pushing for a short 1.4 cycle that focuses on getting a lot of Rust stuff squared away. Having NAK landed but not supported for cross building might be helpful in lighting that fire ;)
22:47 dcbaker: for Meson that is
22:48 gfxstrand: So does that mean you'll ACK the MR and I can burn it all down?
22:50 dcbaker: sure, ack :)
22:50 dcbaker: I did have a couple of patches on your last version... let me see if those are still relavent
22:50 gfxstrand: Sure
22:50 gfxstrand: Also feel free to tell me to re-order stuff for less breakage
22:50 gfxstrand: Some of it might be a bit painful but I'm happy to try
22:53 dcbaker: I personally hate re-ordering of big giant piles of newness, and grumble when others ask me to do that, so I will not
22:53 gfxstrand: dcbaker: I'm going to look at a couple more things tomorrow and then we'll merge it, I think.
22:53 gfxstrand: dcbaker: Well, the thing that really sucks is that meson doesn't take kindly to updating wraps
22:54 gfxstrand: And I do that mid-branch, I think.
22:54 gfxstrand: I'll try to rebase that out tomorrow
22:54 dcbaker: I think you can do `import('rust')` without the `unstable-` bit since you have >= 1.3 required; I think for the same reason you can do `rust_abi : 'c'` instead of `rust_crate_type`
22:55 dcbaker: I think otherwise everything looks fine to me, and I'm of the "start having good commit hygiene after we merge giant features" camp
22:58 gfxstrand: Yeah, I just don't want to cause massive bisect pain
22:58 gfxstrand: Then again, no one who isn't building NVK will ever see that so maybe meh?
22:59 gfxstrand: Yeah, looks like I already dealt with that.
23:04 gfxstrand: Oh, great... the python wheel package doesn't build on f39
23:05 daniels: gfxstrand: I had that earlier but it resolved itself with an update - if the python dep is version-locked, try updating
23:06 gfxstrand: daniels: I'm using the shell script in mesa. Do we need to bump the versions in there?
23:09 daniels: gfxstrand: if you mean ci_run_n_monitor.sh, iirc you need to nuke .gitlab-ci/bin/venv/
23:10 gfxstrand: I don't have a .gitlab-ci/bin/venv
23:10 daniels: fun. tree up to date?
23:10 gfxstrand: yeah
23:11 gfxstrand: Oh, .venv
23:12 daniels: yeah, sorry
23:16 gfxstrand: Looks like ruamel.yaml.clib has an update which fixes it but aiohttp doesn't
23:18 gfxstrand: 3.0.0b0 seems to fix it
23:24 gfxstrand: daniels: ttps://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25999
23:24 gfxstrand: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25999
23:31 daniels: DavidHeidelberg: ^
23:33 daniels: gfxstrand: thanks for updating
23:36 DavidHeidelberg: daniels: thx, lgtm, gallo[m] MR will remove httpaio anyway soon :D
23:37 gfxstrand: Cool.
23:37 gfxstrand: This should at least alleviate a few surprises for Fedora users. :)
23:37 gfxstrand: Or anyone else who gets a surprise Python 3.12 update
23:37 DavidHeidelberg: gfxstrand: thank you for that, if you want to merge it, go ahead :)
23:38 gfxstrand: Already assigned
23:38 DavidHeidelberg: perfecto! muy bien!
23:39 gfxstrand: Ugh... Merging NAK is going to mean updating meson in the build containers....
23:39 airlied: life choices :-P
23:40 gfxstrand: I think this is a problem for tomorrow's me.
23:40 airlied: does it just matter if nvk/nak is enabled?
23:40 airlied: or will everyone suddenly need meson 1.3
23:40 gfxstrand: Oh, you're getting NAK the moment you ask for NVK
23:40 gfxstrand: But only NVK people will
23:40 gfxstrand: But CI builds everything so....
23:40 bnieuwenhuizen: just don't build NVK in CI
23:40 airlied: ah cool should scare distros away from packaging it ifor a while :-P
23:43 daniels: gfxstrand: happy to talk you through it tomorrow then
23:43 gfxstrand: I kinda half-remember
23:43 gfxstrand: Trying to find meson versions now
23:44 daniels: atm it's installed from debian stable, so you'd have to remove those from the debian package lists in .gitlab-ci/container/*.sh and add the pip call like in the fedora one
23:44 gfxstrand: We're already doing that
23:44 daniels: righto
23:45 daniels: in that case, just adjust the relevant versions and bump the image tags in .gitlab-ci/image-tags.yaml
23:49 gfxstrand: The real question is whether or not pip will be happy with the meson version I requested
23:53 airlied: I do wonder how to get the rust deps without wraps, I've installed a bunch of packagse but they don't seem to be picked up
23:53 gfxstrand: Xavier has meson PRs for that
23:53 gfxstrand: They even mostly work if you pull all the right branches together
23:53 airlied: ah meson needs more work, okay I'll suck up wraps for now
23:54 gfxstrand: airlied: https://gitlab.freedesktop.org/gfxstrand/mesa/-/commit/484fd6bc4c37bd535f4327ac6537ef52291888e4
23:55 gfxstrand: This whole driver project has been one big exercise in "Just do the thing and trust the other folks to do their parts"
23:55 gfxstrand: And so far... it's kinda working.
23:55 gfxstrand: NGL, I'm a bit surprised that it's all coming together as well as it is.
23:56 gfxstrand: Speaking of... airlied: How's GSP?
23:56 gfxstrand: :P