00:33Lynne: airlied: what's wm_invalid? I don't see it in any code
00:51airlied: Lynne: gm_invalid in ffmpeg sorry
00:51airlied: the code to derive it is in get_shear_params_valid
01:01Lynne: ah, yeah, it's pretty reasonable to ask the parser to validate them
01:03Lynne: I'll put it in StdVideoAV1MESAGlobalMotionFlags
02:54kurufu: Maybe this isnt quite the right place, but is it expected for glTexImage2D with NULL data argument to actually set gpu memory? I see a huge perf regression on dg2 due to aux initialization that isnt on any other drivers or integrated chips.
02:56kurufu: or if it is happening in integrated chips its so fast as to be unmeasurable.
11:02MrCooper: lima-mali450-piglit:arm64 2/2 failed due to oom-killer: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/36346183
11:14MrCooper: same on first retry, second retry passed
11:50MrCooper: bnieuwenhuizen: out of curiosity, why are you interested in explicit sync in the X11 (and Wayland) protocol? Aren't gfxstrand's ioctls enough to disable implicit sync in RADV?
13:21gawin: am I right that gitlab recently hasn't been sending some mails?
13:27daniels: gawin: nope, it's been working fine for me
13:31DavidHeidelberg[m]: MrCooper: when 2G of zram is not enough...
13:59enunes: MrCooper: DavidHeidelberg[m]: hmm that failure is not any known issue, we have been running piglit in CI for a very long time and I don't remember seeing it happen
14:03DavidHeidelberg[m]: enunes: for some reason when replaced xorg with weston for traces, traces run earlier than weston bringup.. Have to investigate. But for angle traces it does work reliably... :D
14:26jenatali: Is there a label for backports? Or some other way that release maintainers prefer to be notified of backport MRs?
14:46karolherbst: Fixes: tags or Cc: mesa-stable?
14:47karolherbst: ohh you mean MRs...
14:57kisak: jenatali: merge requests targeting staging/##.# should be enough to get the release maintainer's attention. If you think something fell through the cracks, then you can find who is managing that release branch at https://docs.mesa3d.org/release-calendar.html and give them a ping on the merge request.
15:03jenatali: Mmkay, just wasn't sure if the targeted MR would notify them or if there was some other process to let them know
16:22zackr: tzimmermann, mripard, mlankhorst: i have two fixes that should go in drm-misc-fixes but unfortunately will conflict between drm-misc-next and drm-misc-fixes. is there a preferred way of resolving it ahead? i thought of submitting them to drm-misc-next and then cherry-picking and resolving on drm-misc-fixes to record the resolve and pushing the two branches then
16:29mripard: zackr: apply it to drm-misc-fixes, and fix the merge conflict in tip
16:33mripard: there's no need to apply it twice
17:13Kayden: mareko, pepp: how's https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21039 going? looks like there are some reviews but maybe questions still? or just marge not wanting to marge
17:13Kayden: gfxstrand and I have a fix for the rise of the tomb raider hangs, and together those were the last two things blocking the 23.0 release
17:26Piraty: enunes: thanks for https://gitlab.freedesktop.org/enunes/mesa/-/commit/81e0adaebbc45a5017137c1ef36c15d52707fb20 . i run it on pinephone for a day now and it seems to fix the thing
17:28enunes: Piraty: thanks for testing, I'll put a MR for it soon
17:31Piraty: great. meanwhile, https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/44204 will just wait. please ping me in case you do
17:32Piraty: or ping me if you need more testing of anything else in this regard
19:22jenatali: Why did this job fail? https://gitlab.freedesktop.org/mesa/mesa/-/jobs/36375888. I don't see any errors in the job output...
19:23zackr: mripard: the patches were written on top of changes that went into drm-misc-next, so the commits that went to dri-devel were on top of, essentially drm-misc-next, that means dim apply on drm-misc-fixes will conflict and once i resolve that the drm-tip will conflict with the opposite of what i just resolved for drm-misc-fixes. so the cherry-pick would eliminate the silly second conflict. but it's just 2 patches so if the double conflict way is
19:23zackr: preferred i'll do it that way. thanks!
19:39zackr: mripard: actually this is a bit of a mess. the patches won't apply through dim apply at all because they were written on top of commits that are in drm-misc-next, so git will throw "error: sha1 information is lacking or useless, error: could not build fake ancestor" i can, of course, apply manually with patch -p1 but then the Link to patchworks points to an email with a different diff
19:42javierm: zackr: I believe there's `dim cherry-pick` for that
19:42javierm: zackr: but if is for fixes in -next, why not push through that or does it have to go to this -rc cycle ?
19:43javierm: zackr: it's quite likely that if it applies cleanly to v6.2, that will be backported by the stable folks if land in v6.3 and has a Fixes: tag
19:45zackr: javierm: the two patches are not for things in -next, they're both security fixes, it just that the code they touch was rewritten in current -next so i wrote them on top of that. i can rewrite them on top of 6.1 and then push them through drm-misc-fixes and eventually resolve via drm-tip but that's definitely not less work than a cherry pick from drm-misc-next
19:47javierm: zackr: another thing you could do then is apply on -next and then post a backported version to stable@
19:48javierm: zackr: that way you only have the patch once in mainline but still is backported to older stable versions
19:49javierm: zackr: option 3 in https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
19:50zackr: javierm: yes, that's a good idea. i'd have to wait for drm-misc-next to be merged to linus' tree for this though, wouldn't i?
19:51javierm: zackr: I don't think so. I believe that once it's pushed to drm-misc-next then you can already post it to stable since the commit sha-1 should be the same?
19:51javierm: zackr: but that's a good question, probably mripard or tzimmermann could give advice here
19:52zackr: javierm: cool, i'll wait until tomorrow to hear from them before doing anything then
19:53javierm: zackr: sounds goods
20:01alyssa: zmike: "vulkan requires that vertex attribute access be aligned to the size of
20:01alyssa: a component for the attribute"
20:01alyssa: do you have a spec citation for this? I can't find one
20:01zmike: oh no not this again
20:02zmike: if I said trust me would that be enough
20:04alyssa: it was to close https://gitlab.freedesktop.org/mesa/mesa/-/issues/5557 but I don't see how the cited spec text implies the need to align things
20:04pendingchaos: alyssa: 22.4.1. Vertex Input Extraction
20:05zmike: yeah, that's the one
20:05zmike: pendingchaos: heroic
20:06alyssa: aha, thank you ^^
20:06alyssa: so no unaligned vertex fetch for AGXV, that's good to know
20:06alyssa: in that case won't bother extending agx_nir_lower_vbo, cause if it's good enough for Zink it's good enough for asahi gl :^)
20:09zmike: smh writing a new gl driver in the current year
20:09alyssa: it's not new
20:09alyssa: strictly there's an icky edge case in the VK text, because they ask for alignment of the final address -- not the inputs
20:10alyssa: which are not equivalent if you only render a single point
20:10alyssa: R32 attribute, a single point, offset=3, stride=17
20:10alyssa: er no
20:10alyssa: lol no I can add
20:10alyssa: nvm
20:11alyssa: input #0 is accessed at offset, so offset must be aligned
20:11alyssa: input #1 is accessed at offset + stride, so since offset is aligned, so is stride
20:11alyssa: yeah ok got it
20:12jenatali: Yep, D3D had to relax our validation to match VK
20:15alyssa: jenatali: what case needs to be relaxed..?
20:15alyssa: drawing zero points? :~P
20:15jenatali: D3D required that the offset within a vertex element needed to be aligned. Instead, the requirement is that the final address needs to be aligned
20:17alyssa: What case does that make a difference?
20:17alyssa: unaligned buffer + unaligned offset => aligned address?
20:17alyssa: (offset 1 into buffer 0xdeadbeef or something?)
20:17jenatali: Yep, pretty much
20:17alyssa: yeah ok that should be fine here
20:17anarsoul: Ouch. And the spec allows that?
20:17jenatali: Yeah
20:18alyssa: My question is whether any real GL apps (i.e. not the CTS) use unaligned vertex fetch
20:18alyssa: (and are falling down the Zink u_vbuf translate path of doom)
20:20daniels: jenatali: line 2686
20:21jenatali: daniels: Ah. Thanks, I missed that
20:21alyssa: (despite the fact that most hardware can do the unaligned vertex fetch, at a cost)
22:43danvet: zackr, since we still have -fixes open I'd apply to -next, then cherry-pick over with -x (not sure we have a dim cmd for that) and make sure you land it tomorrow so it doesn't miss the release
22:43danvet: for stable you need to wait until -next is in linus' tree before stable takes it, which I think is not a good idea for these patches
22:43danvet: javierm, ^^
22:44danvet: zackr, also good idea to tell the drm-misc maintainers what you've done in case of conflicts (but drm-tip should catch these too)
22:44danvet: oh also only put the cc: stable onto the version in -fixes, otherwise stable gets it twice and gets very confused
22:45danvet: and if you do miss the release, then drm-misc teams should make sure it at least lands in the big merge window pull (but occasionally something goes amiss in the handover there)
22:45javierm: danvet: ah, I didn't know it was a requirement to actually land in linus' tree to post to stable
22:46danvet: mripard, mlankhorst ^^ fyi
22:46javierm: danvet: and yeah, we do have a -x command in dim: `dim cherry-pick`
22:47javierm: it does a `it cherry-pick -s -x -e`
22:47danvet: well I'm never sure whether that only works for drm-intel or also misc :-)
22:47javierm: danvet: I've used for misc in the past so I can say that worked for me at least :)
22:47danvet: ah yeah that's the one
22:47danvet: zackr, dim cherry-pick is your friend
22:49javierm: danvet: also, since commit 281550897a58 ("dim: Consider fix-of-fix for -fixes cherry picking") it can even do transitive cherry-picks which is awesome
22:49javierm: thanks to rodrigovivi
22:49danvet: weaponized bash scripting is scary
22:49javierm: danvet: s/weaponized// :)
23:23gfxstrand: dschuermann_: Sorry review on continues has taken so long. This is apparently NIR week, so I'm going to try and get a solid full review done. It's 5:30 PM now so I may not get through it all tonight but I'll hopefully be all the way through or blocked tomorrow.