08:30 sima: airlied, agd5f I guess I pulled in some warnings that I didn't spot :-/
08:31 sima: https://lore.kernel.org/dri-devel/?q=sfr+amdgpu
08:31 airlied: sima: it's been a week for it, I forgot to put Linus in the to for the last fixes pull
08:31 sima: jani, rodrigovivi https://lore.kernel.org/dri-devel/774fa28d-b196-0030-2fb2-5d5fb8a7d1cc@intel.com/ also one from intel
08:31 sima: airlied, did he not take it?
08:32 sima: the warnings where all drm-next pulls I processed
08:32 sima: I think at least
08:32 sima: hm all kerneldoc it seems, I don't check that
08:32 airlied: sima: he didn't see it
08:32 sima: oops
08:33 sima: airlied, I guess we could fix dim to make the right selection for a pr to linus' tree
08:33 sima: but iirc you're copying those by hand, so wouldn't help?
08:33 airlied: sima: yeah I just write the emails by hand since gmail
08:33 sima: I occasionally forgot to add lkml/dri-devel so the bot will spot it and send out the confirmation mails
08:35 sima: airlied, I guess bounce it as the first pr for the merge window?
09:34 sima: mripard, for -next-fixes I think it's better to fast-forward to drm-next, with just the merge you're still stuck on -rc1
09:34 sima: which is rather old ...
09:36 sima: -next is also that old
09:36 sima: maybe backmerge the main drm-next pull at least?
09:37 sima: tzimmermann_, your patch set that you just sent doesn't seem to be cc'ed to any list?
09:37 sima: the probe helper one
09:38 tzimmermann: sima, thanks
12:45 mripard: tzimmermann, mlankhorst: https://gitlab.freedesktop.org/drm/maintainer-tools/-/merge_requests/60
12:47 tzimmermann: mripard, ack
12:47 tzimmermann: i apparently cannot ack in gitlab directly
13:50 zmike: who reviews for shaderdb?
13:50 zmike: I have had https://gitlab.freedesktop.org/mesa/shader-db/-/merge_requests/99 waiting for a while
14:07 alyssa: zmike: apparently I don't actually have merge rights for shaderdb
14:08 alyssa: not sure who does actually
14:08 zmike: is marge active in this repo?
14:08 alyssa: judging by https://gitlab.freedesktop.org/mesa/shader-db/-/merge_requests?scope=all&state=merged
14:08 alyssa: at least mareko and rhys have merge
14:19 zmike: pendingchaos: ^
14:24 zmike: ty
15:31 mairacanal: mripard, tzimmermann, sima, I was about to apply a fix for V3D that it is on both drm-next and drm-misc-next, but the patch failed to apply and I'll need to fix conflicts in order to apply it on drm-misc-next-fixes
15:31 mairacanal: it is okay to do that?
15:33 tzimmermann: mairacanal, i'd say it depends on the impact of the fixup
15:35 mairacanal: the problem is that I based the fix-up patch on drm-misc-next and before identifying this issue, i applied a patchset that changed a couple of lines changed below my fix
15:36 mairacanal: but it is just a couple of lines
15:40 sima: mairacanal, if it's just diff context that's different, that's usually easy to handle
15:40 sima: if you need to do actual changes, that's more complicated
15:41 mairacanal: just diff
15:44 sima: yeah that should be fine to rebase and just push
15:44 sima: will be a small conflict when rebuilding drm-tip, but git maybe realize it's the same you already resolved
15:48 mairacanal: okay, i'll apply to drm-misc-next-fixes (resolving the small conflict)
15:48 mairacanal: thanks!
15:59 zmike: eric_engestrom: what do you think about delaying the branchpoint a week so we can ensure https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28378 and https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29771 get landed
15:59 zmike: we're very, very close now
16:00 eric_engestrom: yeah, I'd love to get these landed; not sure it really matters whether that's in 24.2 or 24.3 though?
16:01 zmike: 24.2 means I'll be around to help debug any regressions, 24.3 and I will be on sabbatical
16:01 zmike: one week seems like a reasonable delay
16:12 eric_engestrom: ack
17:00 ondracka: zmike: I'm already building with -Dglvnd=false, so why do I still get the _mesa suffixes?
17:00 zmike: oh there you are
17:00 zmike: I commented again
17:01 zmike: sounds like you aren't really building with glvnd=false if you're getting _mesa suffixes
17:03 ondracka: Well, end of meson config says (in the User defined options section) glvnd: false
17:03 zmike: but it still installs _mesa libs?
17:03 zmike: weird
17:04 zmike: maybe it's just old install remnants
17:04 zmike: glx should be installed as libGL.so
17:07 ondracka: OK, maybe I messed up the meson define, to disable glvnd? Should it be something else than -Dglvnd=false?
17:08 zmike: I think that's it
17:08 zmike: try deleting your installed gl libs in your user prefix
17:08 zmike: and reinstall
17:08 zmike: to ensure you aren't hitting old libs
17:09 ondracka: No that not it, its the meson config, it actually shows GLVND : YES at the top and than glvnd:false in the User defined options
17:10 zmike: huh
17:10 zmike: I have -Dglvnd=false here on my non-glvnd install
17:10 zmike: and that works
17:12 ondracka: https://paste.centos.org/view/1ac6259b here is the meson+ninja log...
17:13 zmike: Dependency libglvnd skipped: feature glvnd disabled
17:13 zmike: in mine
17:13 zmike: if you do `meson configure` in your build dir what does it say for glvnd?
17:14 ondracka: OK, it says auto... than I think its just the User defined options for some reason showing false, but it actually compiles it...
17:15 ondracka: I'll do a completely clean build
17:15 zmike: something changed in the glvnd sections of meson/mesa within the past few months which fucked up most of my systems in this area
17:15 zmike: so you're not alone here
17:15 zmike: I think you just need to do meson configure -Dglvnd=false again in your build dir
17:21 ondracka: OK, I see now in a fresh build fat warning "Option glvnd value false is replaced by disabled" ;-)
17:31 ondracka: zmike: so I think the config is now correct, the glx-create-context-ext-no-config-context test still fails (with different error though), I'll rerun piglit to see for other changes
17:32 zmike: well just run that test and get me the info I requested so I can work on it while you run the full suite
17:32 zmike: I just need the xorg backtrace now
17:33 sghuge: do we have any CTS tests targeting VK_COPY_ACCELERATION_STRUCTURE_MODE_DE/SERIALIZE_KHR copy mode? Trying to understand how does things look like from API persepctive but couldn't find anything or maybe I don't know how to grep it properly :D
17:38 zmike: ondracka: what is the error?
17:45 ondracka: zmike: actually scratch that, after reboot the failing piglit now passes
17:46 zmike: great
17:46 zmike: so we're done here
17:46 ondracka: I'll run a full suite but for now all looks OK
17:56 mareko: do you also get random "fatal: Could not read from remote repository." from gitlab?
17:58 agd5f: mareko, I've been seeing that periodically over the last few days
21:50 dcbaker: Is the expectation that memory allocated in vulkan common code by vk_*alloc will not be cleaned up in error cases, and just falls through until the vkAllocationCallbacks is cleaned up?
23:19 karenthedorf: I'm not a dri dev, only an application dev, but my assumption is that every allocation is matched with a free, even in the face of VK_ERROR_DEVICE_LOST.
23:19 karenthedorf: At least if a custom vkAllocationCallbacks is passed in.
23:44 ishitatsuyuki: yes, there is a CTS test for this too
23:46 karenthedorf: Not all VkAllocationCallbcks can clean themselves up. e.g. one that just logs the allocation and then forwards it to malloc/aligned_alloc.