00:00 alyssa: nouveau/codegen seems to handle indirects but honestly I can't tell what it's doing at a glance and that's concerning
00:00 gfxstrand: That's most of nouveau/codegen, TBF.
00:01 alyssa: yeah...
00:01 alyssa: does nvidia have GPRF indirects?
00:01 alyssa: and do you plan to use them in NAK?
00:01 alyssa: if not we can make codegen stop using them to improve NAK-by-comparison ;-P
00:03 alyssa: likewise can't tell what r600/sfn is doing at a glance..
00:04 alyssa: suddenly I'm feeling really good about the midgard compiler
00:05 gfxstrand: lmao
00:06 alyssa: should be straightforward enough to wire in load/store_array to NTT, I understand that backend :p
00:11 alyssa: But, definitely not a doing project
00:11 alyssa: *today
00:35 jenatali: gfxstrand: When you get a chance I sent a WSI patch your way earlier this week
00:37 gfxstrand: jenatali: Ok. link?
00:37 jenatali: One sec
00:37 jenatali: gfxstrand: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22298
00:38 jenatali: The last missing piece to get DOOM Eternal working
00:39 gfxstrand: jenatali: Oh, well that's gnarly
00:39 jenatali: Yep
00:39 jenatali: The app leaks surfaces and recreates them when you alt+tab
00:40 jenatali: I'm open to other suggestions if this approach is a nak but we'll need something along these lines
00:58 robclark: alyssa: yeah, we have indirect const and gpr which can (usually) be folded directly into alu instructions.. tho maybe we could treat indirects as special kinda of ssa src instruction, idk
00:59 robclark: I guess in theory in the nir->ir3 pass they could just be mov's w/ indirect src and then let the ir3 cp pass gobble them up.. but I guess there is enough shader db to know if anything regressed
01:38 alyssa: robclark: I don't have a coherent plan yet
01:38 alyssa: but, ir3 is not the backend I'm worried about, because I actually understand ir3 :-p
01:38 alyssa: it's the mix of C++ and vec4 that gets me ;)
02:38 mareko: trying to figure out how move uniform blocks from one NIR shader to another...
08:27 lina: I think I give up on drm_sched... I just ran into another UAF...
08:27 lina: Christian is right, this design assumes the scheduler outlives everything else.
08:28 lina: Unfortunately it even has random asynchronous cleanup code
08:29 lina: So really I don't see how I can use this in a one-scheduler-per-queue model without just keeping references to every submitted job fence and waiting on everything before freeing the scheduler.
08:29 lina: And this is impossible to safely abstractin Rust
08:41 lina: Actually fences aren't enough, since those get signaled before the job gets freed, and that's too early.
11:51 kchibisov: Am I correct that mesa update is required to silence new `warnings` from mesa in wayland log? Should you call `eglTerminate` to not ever see them in your project or something less involved like dropping context will work just fine?
11:54 kchibisov: New warnings as in "from 1.22" bump about proxies being alive.
12:10 emersion: kchibisov: these have been fixed but yeah maybe not released
12:12 kchibisov: emersion: do I need eglTerminate() for that?
12:12 emersion: not sure
12:12 kchibisov: I hope not.
12:24 kchibisov: Hm, from what I understand the issue is purely to the drop order of the mesa internal queue, so as long as mesa sanely drops stuff attached to its own queue I won't see an issue. It's not like I have to explicitly `eglTerminate` or force mesa to dropping the wayland queue when I've closed the main queue in my application, right?
12:29 emersion: i think you get warnings when a non-default queue is destroyed
12:29 emersion: maybe the mesa queue is not destroyed if you don't eglTerminate
12:29 emersion: why do you want not to call eglTerminate out of curiosity?
12:30 kchibisov: You can't do that as a library inside your destructor.
12:31 emersion: because it might bring down other EGL contexts?
12:31 kchibisov: EGLDisplay is sort of reference to the global singleton, the Display in the spec is not refcounted, and given that you have behavior like "pass the same args to eglCreateDisplay"(can spell it wrong) you have no safe control over it.
12:32 kchibisov: pass same args, get the same display behavior.
12:32 emersion: kchibisov: there is an ext to refcount the EGLDisplay
12:32 emersion: and also another one to guarantee that a fresh EGLDisplay is returned, iirc
12:33 kchibisov: But you'll have 3 different path in your library handling all of them.
12:33 emersion: for wlroots we turn it on and then prey
12:33 emersion: iirc
12:34 kchibisov: Yeah, given that wlroots is mesa only you're fine.
12:34 kchibisov: yet, glutin(lib I'm maintaining) works on all possible platforms.
12:35 emersion: i think it's not that bad to use the ext
12:35 emersion: if (ext) eglTerminate();
12:35 emersion: basically
12:35 kchibisov: I mean, I'll likely add it.
12:35 emersion: and continue leaking the stuff if the ext is missing
12:35 kchibisov: Given that you've enlightened, that there's an extension.
12:35 emersion: a bit annoyng that there are two specs for the same purpose that said
12:36 kchibisov: emersion: I mean, it's not like we're leaking, you can call the function yourself.
12:36 emersion: well
12:36 kchibisov: it's just "manual resource management".
12:36 emersion: if a lib allocates an EGLDisplay, i'd expect the lib to clean it up properly
12:36 emersion: just like the rest of the resources
12:36 emersion: but yeah, it's not that of a big deal
12:36 kchibisov: Yeah, that's true, it's just EGLDisplay is a reference.
12:37 kchibisov: Unless you're using extensions.
12:37 kchibisov: From a semantic speaking with default EGL, library isn't owning the EGLDisplay.
12:45 kchibisov: Thanks for mentioning the extension, our original research wrt calling/not calling was around that extensions was created, so it sort of missed.
12:53 kchibisov: If you happen to know how the other extension is named "About getting a new display for each eglGetPlatformDisplayEXT" I'd like to know it as well.
12:55 kchibisov: The refcounting one I've found, given that it obviously named in the `EGL-Registry`.
12:57 emersion: kchibisov: ah, not yet merged: https://github.com/KhronosGroup/EGL-Registry/pull/156
13:11 kchibisov: emersion: thanks.
14:38 dj-death: arg
14:38 dj-death: fourth time CI timeout
14:39 dj-death: is it normal for radv-stoney-vkcts to last 1hour ?
14:41 zmike: you're lucky it doesn't take 2
14:44 hakzsam: I don't think it's normal
15:00 dj-death: my other question is also why do we build mesa 19 times per pipeline on debian ;)
16:56 DavidHeidelberg[m]: dj-death: we like diversity of build
16:57 DavidHeidelberg[m]: Some builds are distributed to the test machines, some tests are build test in different configs
21:18 alyssa: gfxstrand: To be clear, do you want to torch nir_instr_rewrite_src_ssa or not?
21:24 gfxstrand: alyssa: IDK
21:24 gfxstrand: alyssa: I'd like to see a parent != NULL check in `nir_src_rewrite_ssa()` either way
21:28 alyssa: Yeah, added that
21:29 alyssa: gfxstrand: mostly want to know if I should drop the patches or not
21:29 alyssa: ideally we can land this MR sooner than later because it's going to be rebase hell and I'm going on NIR holiday soon
21:30 gfxstrand: Yeah
21:31 alyssa: (and if dropping the extra churn means it can go in sooner, happy to, I'm not attached to it I was mostly having fun with Coccinelle)
21:31 gfxstrand: There's one unaddressed bug in the first patch still, FYI.
21:31 alyssa: yeah i know
21:31 gfxstrand: (I'd have RBd it otherwise)
21:32 gfxstrand: I think let's break that out into a separate MR for now and try to land the rest.
21:32 gfxstrand: I want to think about it
21:32 alyssa: Sounds good
21:38 alyssa: gfxstrand: Also, where are we at with the nir_foreach_use discussions with anholt?
21:44 gfxstrand: alyssa: Given how many other instances there are, I think what you've got is good for now.
21:44 gfxstrand: That one sounds like a pretty big audit.
21:44 gfxstrand: Maybe worthwhile but pretty big
21:47 alyssa: Yeah
21:51 alyssa: gfxstrand: Can I not improve source mods please? ;-p
21:51 alyssa: I've got a ~~plan~~ sketched out hopes & dreams to delete that pass
21:51 gfxstrand: yeah, that's okay
21:52 alyssa: Said hopes & dreams is to make the actual NIR fully SSA (with load/store_reg intrinsics) and no source mods (fneg/fabs/fsat instructions)
21:52 alyssa: and have helpers that produce nir_alu_src/nir_alu_dest from an SSA def
21:53 alyssa: internally chasing SSA to reconstruct what the alu src/dest would have been back when those data structures were part of NIR
21:54 alyssa: so converting backends is straightforwardish, just call into those helpers when translating NIR
21:55 alyssa: since they return the data structure that would otherwise be read directly, this doesn't require plumbing anything through more deeply
21:55 alyssa: (very much a surface level translation for the older backends)
21:55 gfxstrand: I like this possible future. I hope we can get there.
21:55 alyssa: Me too
21:56 alyssa: so that's the backend half
21:56 alyssa: the frontend and NIR core part is a different story
21:56 alyssa: we're using nir_register for a lot of weird shit, apparently
21:57 alyssa: IDK what happens with lower_phis_to_regs, for example
21:57 alyssa: unless it just also turns into intrinsics and that's fine
21:59 alyssa: ngl it would also be nice to torch swizzles but that's an even bigger thing
21:59 alyssa: but I do wonder if opt_algebraic in particular would be sped up by not worrying about swizzles
22:12 alyssa: ok, addressed all the review feedback (some of it punted on)
22:12 alyssa: asahi still seems ok, let's see what CI thinks
22:12 alyssa: anyone want bets on whose drivers I broke? :D
22:13 alyssa: crap, pushed the version with the asahi uapi in there... meh, shouldn't affect CI results
22:14 gfxstrand: Anything we do during optimization can use intrinsics or whatever
22:14 gfxstrand: There's no need for actual register sources for that stuff
22:15 alyssa: right, but I want to rid the IR of register sources entirely
22:15 alyssa: i.e. drop the is_ssa bool from nir_src and make it just an ssa def and a use chain
22:16 gfxstrand: Yes
22:21 gfxstrand: alyssa: Did you mean to push an asahi patch on top?
22:21 gfxstrand: alyssa: Also, why are most of those patches not linking to your gitlab profile?
22:21 alyssa: 1. no
22:21 alyssa: 22:13 alyssa: crap, pushed the version with the asahi uapi in there... meh, shouldn't affect CI results
22:22 alyssa: 2. I unlinked my gitlab profile from my @collabora.com email
22:26 alyssa: 22:12 alyssa: anyone want bets on whose drivers I broke? :D
22:26 alyssa: DXIL this time
22:26 alyssa: take 2
22:27 gfxstrand: alyssa: 2) Why? Mine's still linked with Intel. (-:
22:27 alyssa: 🙃
22:33 HdkR: 23.1 branch is next Wednesday right?
22:33 HdkR: No delays or anything currently? :)
22:47 HdkR: Looks like there is nothing tagged as a release blocker yet in the milestone at least