07:16emersion: bjorn3_gh: pageflip events are already async
07:17airlied: emersion: that docs say they are in response to a request though
07:17emersion: there is no client-response mechanism
07:17emersion: request*
07:17airlied: * This event is sent in response to &DRM_IOCTL_WAIT_VBLANK with the
07:17airlied: * &_DRM_VBLANK_EVENT flag set.
07:18emersion: events are sent in response to something else but that's just the trigger mechanism
07:18emersion: I kind of agree wrt. these events are outside the scope of seat/session management
07:20emersion: https://gitlab.freedesktop.org/mesa/libdrm/-/blob/main/xf86drmMode.c?ref_type=heads#L1074
07:20emersion: we do ignore unknown events, but a cap would be nicer than always sending events
07:21emersion: my point about device hotplug is that you'll need to have events at that level too at some point
07:22emersion: you probably already do need these events for input?
07:26sima: emersion, missing some scrollback, but maybe we should clean out events on dropmaster so they don't leak to the next compositor?
07:26sima: just random thought that crossed my mind
07:27emersion: hmm, I wonder
07:27emersion: if a client has performed a pageflip but never gets the event, that's not great
07:27sima: hm, otoh they're per-fd, really shouldn't be an issue
07:27sima: yeah, maybe a bad idea actually
07:27emersion: bjorn3_gh: we need to be careful around race conditions too
08:14lucaceresoli: mripard: I'd appreciate if you could answer the questions on https://lore.kernel.org/lkml/DL5Q0MLS0KT9.24LJK2Q1L89KP@bootlin.com/
08:15lucaceresoli: mripard: I plan to prepare a v3 this week and it'd be great if if have an agreement beforehand on that one patch, which is the central one
08:15lucaceresoli: mripard: BTW the last 2 questions are kind of mutually exclusive, they are there just to ensure I get your idea
08:31jani: airlied: tzimmermann: I see you've done an -rc1 to drm-next backmerge, and then on to drm-misc-next. I think we need another one with -rc2 due to 3a2c4d55e32a ("treewide: refresh kmalloc_obj() conversions")
08:32tzimmermann: jani, sure. i'll take care of drm-misc-next when drm-net is ready
08:32jani: airlied: tzimmermann: it conflicts with 1ad5e807f716 ("gpu/buddy: replace dual-tree/force_merge with decoupled dirty tracker"), and I'm not comfortable doing the conflict resolution, even if the conflict is fairly small
08:32jani: that's in drm-misc-next
08:33tzimmermann: thanks for the warning
08:33jani: and to be honest, I think 1ad5e807f716 ("gpu/buddy: replace dual-tree/force_merge with decoupled dirty tracker") is much *much* bigger than patches should be. it utterly fails on the "if a git bisect lands on this, do you have a chance of figuring out what it is" test
08:34tzimmermann: urg!
08:34tzimmermann: that commit diff is 2k lines.
08:34jani: single commit, 4 files changed, 1041 insertions(+), 426 deletions(-). yeah sure, rewrite/replace something, but I'm confident it could've been chopped into smaller pieces
08:35jani: and hell, if you're using an LLM to do this, you can tell it to chop it up
08:35tzimmermann: nah, that's not just a mechanical replacement change. it seems full of other changes
08:36jani: not too late to revert :p
08:36tzimmermann: thanks for pointing this out
08:36jani: np
08:38tzimmermann: i don't think it's acceptable for this type of change
08:41jani: bunch of sashiko complaints too *sigh*
08:50airlied: tzimmermann, jani: I'll push rc2 to next/fixes in next hour or so
12:54tzimmermann: jani, i updated drm-misc-next as well
13:13anonymix007[m]: I'm working on a Vulkan instance extension that lets a Vulkan ICD use D3DDDI callbacks instead of D3DKMT* thunks. It would allow implementing layered D3D UMD on top of Vulkan ICDs (with the use of DXVK or WineD3D). I've drafted the header with types and implemented this extension for Venus (WIP implementation for ANV also seems to be working):
13:13anonymix007[m]: https://gitlab.freedesktop.org/anonymix007/mesa/-/blob/venus-win32/include/vulkan/vulkan_d3dddi.h
13:13anonymix007[m]: I'd like to get everyone's comments about the general approach of this extension.
13:54misyl: I am not sure I understand fully what you are proposing here... Do you have a full branch with code? What side is going to be using this d3dddi stuff? I assume the Windows Guest side...? But ANV isn't going to be there so I am confused
14:01anonymix007[m]: I opened an MR with Venus patches a while back: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38731
14:05anonymix007[m]: d3dddi is going to be used by Vulkan ICD inside Windows guest, right. That branch currently only includes Venus, but this can also work on any vDRM-capable ICD and I have a private wip ANV branch.
14:11misyl: I see, you should likely make an MR to Vulkan-Docs with your xml changes there
14:12misyl: Probably a good starting point for discussion there
14:12misyl: who is using the other half of things though? maybe this can be mesa internal and we can just register a dummy extension
14:15anonymix007[m]: I assume the only user will be this: https://github.com/anonymix007/virtio-d3d11
14:15anonymix007[m]: Not sure if mesa is the correct place to house that code though
14:30misyl: maybe worth bringing that into mesa then stuff can just be versioned together?
14:30misyl: if that's your plan
17:10misyl: that is to say, the virglrenderer vs mesa split has been terrible and i don't think we should repeat things like that
20:00bjorn3_gh: emersion: race conditions around what?