08:23 austriancoder: snowy_coder: If you have time, can you review the new concept of !40343 - thanks
09:34 airlied: zmike: you remember why lvp zs/color copies couldnt use resource copy region?
09:36 airlied: ah resource copy region doesn't do depth properly, I wonder can I just make llvmpipe suppor tthat
09:41 airlied: uggh I think another lavapipe == llvmpipe only incoming :)
09:41 mareko: airlied: pipe->blit is the gallium path for Z/S<->color copies, there is a GL extension that uses it, u_blitter implements it
09:43 mareko: the blit mask is also the Z/S aspect mask for this
10:30 jfalempe: tzimmermann: I just pushed 3 fixes for drm_panic to drm-misc-fixes. I fixed a conflict with drm-next in drm-tip, as some code moved to drm_panic_helper.c.
11:10 tzimmermann: jfalempe, ok
11:11 tzimmermann: do i need to do anything?
11:48 jfalempe: tzimmermann: I solved the conflict, so I think it should be good.
11:48 glehmann: mareko: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/45358 is missing a backport tag
11:48 tzimmermann: thanks
11:48 glehmann: another downside of the approve only work flow
11:53 mareko: that statement needs to be supported by long term data
11:57 mareko: anybody who sees a running pipeline with a missing Fixes tag should cancel the pipeline
13:33 dcbaker: Alright, it's monday. eric_engestrom, to rehash. I screwed up the base of the 26.3-rc1 branchpoint somehow (I'm still trying to figure out what the heck I actually did). So -rc1 is not based on the branchpoint *and* has extra commits. I think the general concensus was that the better of the options between "delete the 26.3 branch and start over with -rc2" and "rebase in the branchpoint" was start over. what do you think? And, if you're cool
13:33 dcbaker: with the delete plan can you either unlock the 26.3 branch so I can force push it, or delete it so I can start over?
14:53 simon-perretta-img: Is there a nir pass (combination?) which can help transform "%0 = @load_scratch 0x0; ... %99 = @load_scratch 0x18c; @store_scratch %0, 0x190; ... @store_scratch %99, 0x7cc;" into "%0 = @load_scratch 0x0; @store_scratch %0, 0x190; ..."?
14:53 simon-perretta-img: Example offsets aren't that meaningful, just showing that they're constant and the ranges are distinct/don't alias; this is basically a vec4 array being copied into another
14:56 karolherbst: simon-perretta-img: there is some issue with copy propagation you might run into here
14:56 karolherbst: depending on the deref chains, we fail to recognize those things
14:56 simon-perretta-img: Oh, interesting
14:57 karolherbst: in CL this e.g. happens if you do type punning... so the deref chains are different (different types) and we have a store/load cycle even though it could be an ssa value
14:58 karolherbst: simon-perretta-img: there has been some discussion here: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/44457
14:58 karolherbst: not sure if it's the same thing you are seeing, but...
14:58 karolherbst: I'm sure it's related
14:59 simon-perretta-img: karolherbst: I'll check it out, cheers
14:59 karolherbst: simon-perretta-img: if you want to fix it, the current idea is to have a pass that normalizes types to always use uint for load/stores there and hope that copy_prop would pick it up then
15:03 karolherbst: simon-perretta-img: ohh wait.. I think I failed to parse the nir shader.. in your case it's about register pressure?
15:03 simon-perretta-img: Yeah I was about to say, having looked at the MR I don't think it's related
15:04 simon-perretta-img: karolherbst: Yep, interleaving the loads/stores would help with register pressure and I was struggling to find a way to do that either in deref form or once lowered to scratch intrs
15:04 karolherbst: though it's something copy prop could also optimize, because load/store scratch cycles are kinda odd things to happen anyway...
15:05 karolherbst: simon-perretta-img: right... I think we don't have a proper instruction scheduler in nir yet, but maybe with opt_sink/opt_move you could do something there
15:05 karolherbst: are there indirects on scratch later on?
15:06 karolherbst: because if not, those should get converted to plain SSA values tho
15:08 simon-perretta-img: karolherbst: Fair, will have a look into sink/move, thanks
15:08 simon-perretta-img: Sadly yes, indirects are present too
15:13 karolherbst: annoying
15:14 simon-perretta-img: I think sink/move are a no-go due to lack of can_reorder on those intrinsics
15:15 zmike: okay, second attempt at fixing AGENTS.md https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/45380
18:20 eric_engestrom: dcbaker: sorry for the slow response time, I was basically away for the weekend (starting thursday)
18:20 eric_engestrom: dcbaker: so, I agree with everything you said; I'm deleting the 26.3 branches and tags, and yeah -rc1 is burned as a tag, so -rc2 is the next one you can make
18:22 eric_engestrom: branches staging/26.3 and 26.3 are deleted
18:22 dcbaker: eric_engestrom: Sounds good. I'll plan to just make -rc2 as normal on Wednesday, with anything that's been nominated applied on top of the correct branchpoint
18:22 eric_engestrom: -rc1 tag deleted, but I haven't touched the branchpoint tag, it looks correct to me
18:22 dcbaker: Thank you!
18:23 dcbaker: And also, no need to apologize for real life :)
18:23 eric_engestrom: well, it was unfortunate timing :/
18:24 eric_engestrom: anyway, we have a clean slate now, just double-check what you do next time you try :P
18:24 dcbaker: Is there ever a good time to make a difficult to recover mistake?
18:24 eric_engestrom: well, having other people around who know about these things and have the ability to do something about it helps ^^
18:25 dcbaker: haha, I will. I'm 50% tempted to write a script to throw in bin to create the branchpoint automatically
18:25 dcbaker: to avoid such issues
18:26 dcbaker: okay, lets start with the staging branch this time, since I can always force push that... lol
18:28 mareko: you can also ask for more permissions
18:29 dcbaker: I probably should. I did mention that in the Meta issue about membership
18:30 eric_engestrom: +1; I've just made you a `Maintainer`, hopefully that's enough for what you'd need to do
18:48 dcbaker: Thanks!
18:59 anholt: sccache MR up for build time improvements for us. https://github.com/mozilla/sccache/pull/2919
20:58 airlied: rodrigovivi: btw what's next for the merged -next to -next tree?