07:27 mlankhorst: lumag: is there any reason you need it specifically?
07:29 mlankhorst: lumag: is it part of drm/drm-next? If not might need to get sima or airlied to forward first. :)
07:30 sima: I've missed earlier context, some backmerge needed?
07:30 mlankhorst: 00:43 < lumag> mlankhorst, narmstrong_: is there a way to merge drm-misc-next-2025-07-17 to the drm-misc-next-fixes branch? Otherwise we have 77 commits in Linus's tree which are not a
07:30 mlankhorst: part of drm-misc-fixes-next.
07:30 mlankhorst: 00:45 < lumag> mlankhorst, narmstrong_: e.g. I tried picking up https://lore.kernel.org/dri-devel/20250716125602.3166573-1-andyshrk@163.com/ , but I could not because offending commit
07:31 mlankhorst: is merged to Linus's tree, but it's not a part of drm-misc-next-fixes
07:31 mlankhorst: context^
07:32 lumag: mlankhorst: it is (otherwise it wouldn't have been merged into Linus tree)
07:32 mlankhorst: Yeah, we can backmerge drm-next, that should be fine
07:32 lumag: sima: ^^
07:33 sima: ah did we do anonther drm-misc-next when drm-misc-next-fixes was already branched?
07:33 lumag: mlankhorst: yes, either drm/drm-next or just drm-misc-next-2025-07-17
07:33 sima: and yeah should be fine, just fish out the actual patch you need
07:34 lumag: sima: yes:-(
07:34 sima: as a reason for the merge commit I mean, not fish out the individual patch with a cherry pci
07:34 sima: *pick
07:35 mlankhorst: Pushed!
07:35 lumag: mlankhorst: thanks!
07:38 mlankhorst: Interesting, I assumed since it was in Linus tree, that it was merged outside of drm-misc-next, but looks like drm-misc-next-fixes just opened a bit too early. :)
07:41 lumag: mlankhorst: I'm sorry, I should have been more explicit
19:10 mlankhorst: airlied: not sure what time you are available, but can I ping you on the status of drm memcg accounting patches?
19:13 airlied: mlankhorst: here now, but in meetings
19:27 mlankhorst: Ok I'll wait
19:41 airlied: mlankhorst: feel free to ask me things and I'll reply in between the bits :-), the status was I was mostly waiting for Christian to get back, which he has now
19:42 mlankhorst: Yeah, as I mentioned tried the patches, ran into a few bugs, wonder if you are going to respin so I can try that
19:42 airlied: last respin is still what I have here
19:43 mlankhorst: Yeah that broke :)
19:44 airlied: https://lore.kernel.org/dri-devel/20250722014942.1878844-1-airlied@gmail.com/ okay feel free to drop me feedback :-)
19:45 mlankhorst: Yeah will do so
20:02 anholt: gfxstrand: is there a reason we don't set VK_SYNC_FEATURE_GPU_MULTI_WAIT on vk_drm_syncobj by default? it would always be supported, right?
21:05 gfxstrand: anholt: Yeah. That's weird
21:06 gfxstrand: Oh, great. RADV and panvk are hacking around it. :rolling_eyes:
21:07 anholt: Cool. If you're in agreement, https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36563 will go delete more code.
21:08 xeyler: linusw: would you mind reviewing the following? https://lore.kernel.org/all/20250731032343.1258366-4-me@brighamcampbell.com/
21:09 gfxstrand: I think the reason I didn't is because vk_drm_syncobj_get_type returns a single type for both binary and timeline syncobjs
21:10 gfxstrand: anholt: ^^
21:10 gfxstrand: But as long as we're clear that multi-wait only applies if VK_SYNC_IS_TIMELINE is not set then I think we're fine
21:13 anholt: I can add "non-timeline" to the comment describing the flag.
21:15 gfxstrand: :+1
21:19 anholt: now back to trying to figure out the maze of semaphores and fences going on in presentation