02:30 mareko: I wonder if we should have a different AI policy for superhuman AI models
02:33 HdkR: We should have a different policy for 10x engineers while we're at it.
02:34 zmike: there are no 10x engineers, only 10x shitposters
02:34 mareko: ... says the 100x engineer
02:34 HdkR: Red Bull's advertising lied to me!
02:49 orowith2os: 10x engineers are cool, now get ready for .01x engineers
02:49 orowith2os: using this to refer to people who offload their thinking to largely just LLMs now lmao
02:49 zmike: you mean https://www.youtube.com/watch?v=i7aQig-wjYA
02:50 mareko: crossposting my experience with AI: I've come to the realization that running VK CTS after coding is a waste of time, just ask Astra to tell you what all the bugs are
02:50 orowith2os: @zmike holy shit, I love this.
02:51 zmike: it's a good channel.
02:52 orowith2os: "I don't, and I don't wanna know" he is my spirit animal.
02:53 orowith2os: @zmike I also just so happened to stumble across https://www.supergoodcode.com/againicl/ again and it's making me audibly laugh
02:53 zmike: sometimes I feel like I'm still trapped in karol's basement
02:53 orowith2os: LMFAO
02:54 orowith2os: I think karol would keep me in his basement too if I started to dip my hands any more into rusticl 🙃
02:54 orowith2os: (he's been trying to get me to do some fp work for gallium drivers)
02:54 zmike: don't be fooled
02:54 zmike: cl is a ponzi scheme from big triangle
02:56 mareko: AI could take rusticl to the next level
02:56 Sachiel: how much do they pay you to constantly promote it?
02:56 zmike: not enough, clearly
02:56 orowith2os: probably a nickel, which isn't a lot, but it adds up over time.
02:57 orowith2os:has only seen mareko mention it once, maybe twice
02:57 mareko: Sachiel: I pay them ;)
02:59 orowith2os: is linyaa active on IRC at all, btw?
02:59 orowith2os: I have a bone to pick with her on some EGL spec stuff.
02:59 Sachiel: haven't seen her in a while
02:59 zmike: long while
02:59 Sachiel: not sure she works on anything related anymore
03:00 mareko: I was a sceptic until 2 weeks ago when I tried the model and then my whole worldview collapsed
03:01 mareko: I wasn't too impressed with their Sol model, it can do coding alright, it just didn't seem as smart as I needed it to be
03:03 orowith2os: oh, I found her, just on Discord. hopefully it's a bit more reliable method of contact then IRC...
03:03 orowith2os: coolio
03:03 orowith2os: now I get to wait for Khronos to move (slowly) 🙃
03:04 orowith2os: @zmike question, since I think it concerns zink and how egl<->vk wsi interact.
03:04 orowith2os: Do you know does it handle protocol objects under Wayland that get bound in EGL, and also VK?
03:05 zmike: ...what
03:05 orowith2os: :)
03:05 zmike: the only interaction between egl and vk is that it goes through kopper.c which calls into zink_kopper.c
03:05 orowith2os: if I bind to something like wp_tearing_control_v1 in EGL, do you know what happens if the client is running on zink as well?
03:05 orowith2os: since vk wsi also binds to it
03:06 orowith2os: I'm... not entirely sure how the two interact there
03:06 orowith2os: maybe I'm just not insane enough to understand Mesa's EGL impl in its entirety
03:07 zmike: pretty sure the egl wl_display gets passed down into teh vk driver
03:08 zmike: check kopperSetSurfaceCreateInfo
03:08 orowith2os: the idea is that VK_PRESENT_MODE_FIFO_RELAXED_KHR should map to EGL_SWAP_TEARING_HINT_ASYNC_EXT
03:08 zmike: ah
03:08 orowith2os: or swapinterval of 0 should be immediate (with tearing) if it's also EGL_SWAP_TEARING_HINT_ASYNC_EXT
03:08 zmike: yeah so you just plumb it through to the present mode hook
03:08 zmike: kopperSetSwapInterval
03:09 orowith2os: gotcha, so stop egl from binding to wp_tearing_control_v1 entirely if zink is in use?
03:09 zmike: I'm too tired to remember the exact mechanics of who binds what
03:09 zmike: probably
03:10 zmike: and with that last bit of wisdom I'm gonna crash
03:10 orowith2os: have fun :)
03:10 orowith2os: I see where the trail ends so I'll note it down for later
03:12 orowith2os: oh, this is going to be fun...
03:13 orowith2os: kopperSetSwapInterval might do good to take in the actual surface, so it can check preferred tearing state there...
03:13 orowith2os: feels bad though, so maybe I don't jump to doing that immediately.
07:14 airlied: rejoice "AI-policy-marker: biblioklept"
08:40 pq: airlied, can you tell me more?
11:26 zmike: nowrep: I think that should be all your comments addressed
11:29 nowrep: except the interlaced support, yeah
11:29 zmike: yeah I'm trying to keep scope minimal for the first impl
11:29 zmike: just to get the bones landed
11:29 zmike: it's easier to start adding stuff incrementally then
11:29 nowrep: alriht
11:29 zmike: if you think interlaced is critical for that then I can add it
11:30 nowrep: it's fine if it's added later
11:30 zmike: ok
11:31 zmike: I think plan of attack for next steps will be 1) interlaced 2) require maintenance1 so we can do independent profile and fix all that up
11:31 orowith2os: ah, I see I've entered zmike's waking hours.
11:31 zmike: it should be much easier to add support for other types of content once that's done
11:34 zmike: eric_engestrom / dcbaker: I don't know who is doing rc1, but we probably want https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/45244 to land in it so people have functional fbconfigs
12:48 zamundaaa[m]: <dcbaker> "PSA: If there are MRs that are..." <- I don't have permissions to change the milestone, but it would be great if we could still get https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33344 into the release
13:51 dcbaker: zamundaaa: I've re-assigned that to marge
13:52 mripard: jani: Adrinael: Could you give a look at https://lore.kernel.org/r/20260916095159.2896630-1-mripard@kernel.org ? thanks
13:52 zamundaaa[m]: dcbaker: thanks!
13:59 dcbaker: PSA: We had a lot of last minute requests for important fixes to go in before 26.3 branched. I'm planning to put the commit for the branchpoint in to marge about 13:00 PDT today. If there are still things that you want that don't make it, let me know and we'll pull them in for -rc2
13:59 zmike: dcbaker: my thing already landed
14:01 dcbaker: zmike: sweet.
14:01 zmike: I'm doing my part!
14:02 dcbaker: I'm helping!
14:41 karolherbst: I played around doing VRAM -> CPU copies via userptrs + resource_copy_region in rusticl and apparently at least with the CL model it's a lot faster on iris...
18:52 airlied: pq: the rule to make agents stick in a magic work if they create a commit msg seems to be working
18:55 HdkR: hah
20:30 dcbaker: PSA: I have now placed the branchpoint MR into the marge queue. Anything you assign to marge after that will not be in -rc1, and will need to be backported. Add Backport-to: and Fixes: tags as appropriate
20:30 zmike: hooray
22:17 karolherbst: util_queue_finish has a data race :'(
22:17 karolherbst: at `util_queue_fence_wait(&fences[i]);` I see queue->num_threads to be 0 :)
22:18 karolherbst: and it dead-locks..
22:28 karolherbst: ohh maybe it's just some race between when the context and screens get destroyed.. maybe I rusticl can mess up the order (e.g. destroy all pipe_contexts and the pipe_screen at the same time...)
22:28 karolherbst: that could mess things I figure
22:29 karolherbst: but that shouldn't really happen.. weird
22:50 karolherbst: okay.. I think I found it.. that's a purely evil one
22:59 CounterPillow: I think code should be a little evil sometimes to spice things up
23:01 karolherbst: this one is just... super evil
23:01 karolherbst: mhh I think it was something else in the end...
23:02 orowith2os: mueheheheheh
23:05 karolherbst: anyway.. I have a situation where util_queue_finish and util_queue_kill_threads get called concurrently and the threads get nuked before the fences can be signaled :'(
23:06 zmike: have you considered not doing that
23:07 karolherbst: it's threads tearing down... one destroys a pipe_context and the other is calling the u_queue atexit handler 🙃
23:08 karolherbst: sadly CL doesn't have any "deinit" function... so this is just wonderful
23:08 HdkR: Time for robust futexes.
23:08 karolherbst: mhhh
23:17 HdkR: FEX will break your robust futexes for you though </s>