00:23 dcbaker: soreau: it’s been discussed. Also discussed changing the way libdrm is distributed
00:35 abhinav__: jani vsyrjala Hi, we wanted to re-use https://gitlab.freedesktop.org/drm/msm/-/blob/msm-next/drivers/gpu/drm/i915/display/intel_dp.c#L4113 API for one of our features for msm so wanted to move it to a generic helper location. I was thinking of drm_dp_helper but lumag suggested hdmi.c .... so we wanted to get your opinion on what would be more
00:35 abhinav__: appropriate for this API
09:54 thellstrom: mripard: https://lore.kernel.org/dri-devel/20240209140818.106685-1-michal.winiarski@intel.com, ack to push this to drm-misc-next? Fixes xe CI compilation failure.
09:54 mripard: thellstrom: ack
09:55 thellstrom: Thx
11:07 glehmann: looks like the isl docs are broken in CI and are causing unrelated MRs to fail? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18540
11:47 jani: glehmann: I presume caused by https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27540 - but how did that not fail? did it even run the docs tests?
11:48 jani: specifically caused by https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27540/diffs?commit_id=a52c1994aa11febf0c54d63e46798b3204c180a0
11:55 daniels: janesma: ^
11:56 daniels: jani: the isl mr didn't change any docs, so we didn't re-run the doc build ...
11:58 jani: daniels: yeah one downside of using clang to parse source is that it actually needs to be proper C
11:58 daniels: also the files it's attempting to parse need to exist
11:59 jani: daniels: looks like it'll be sufficient to add an empty stub file under docs/header-stubs. I'll send a MR after a meeting
11:59 daniels: kiitos :)
11:59 jani: eipä kestä!
12:58 jani: daniels: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27573
12:59 jani: test-docs-mr job succeeds
13:04 jani: glehmann: ^
13:22 glehmann: jani: thanks
13:24 jani: glehmann: np, turned out to be simple
14:03 Hazematman: Hey does anyone know of a portable way I can create a sync file from userspace in Linux? I'm looking at the `VK_KHR_external_fence_fd` & `VK_KHR_external_semaphore_fd` extensions for lavapipe and I think because of the "copy payload transference semantics" of sync files I could get away with returning a sync file that is always signaled for exporting a fence/semaphore? Right now I think I could do this using libdrm `drmSyncobjCreate` &
14:03 Hazematman: `drmSyncobjExportSyncFile`. But I want to try and figure out if there is a way I could do this without using drm at all
14:05 dj-death: Hazematman: you can do the ioctl yourself
14:06 Hazematman: dj-death: the drm ioctl? Or are you implying there is an ioctl to create sync files? I'm trying to avoid not just libdrm right now but the entire drm API so just doing the drm ioctl myself doesn't solve the problem if I don't have a drm driver available
14:11 dj-death: Hazematman: ah right
14:12 dj-death: I know IGT uses /dev/sw_sync
14:13 dj-death: but maybe you can't turn that on without being root
14:16 Hazematman: Did not know about `/dev/sw_sync` let me check that out and see if it works. Thanks dj-death !
14:20 dj-death: daniels: let me know if you're happy with !26797
14:28 daniels: dj-death: c'est bon
14:29 daniels: /dev/sw_sync is not portable; you can use the drm functions to create a syncobj (which is a drm-only concept, not generic), but there is no generic way to materialise a sync_file from userspace and never will be
14:29 daniels: sync_file is explicitly only there to represent work which has already been committed to the hardware (or at least flushed down to the kernel) and can be relied upon to complete 'pretty quickly'; allowing userspace to control sync_files completely breaks that promise
14:34 dj-death: daniels: thanks :)
14:34 daniels: np!
14:34 dj-death: so now I have to fix the sphinx stuff
14:36 daniels: my condolences
14:55 Hazematman: <daniels> "sync_file is explicitly only..." <- I don't really need a generic sync_file. Because of the quirks on how lavapipe/llvmpipe works and how the vulkan spec states that you can only export a sync file for a sync object that is signaled or queued to be signaled, the sync file that would be exported will always be signaled. Having the equivalent of `dma_fence_get_stub` from userspace would be useful in this case to get a sync file
14:55 Hazematman: that is always signaled
15:52 vsyrjala: abhinav__: drm_dp_helper.c already has the vsc_sdp_log stuff. seems related. though someone could also start thinking about splitting things up in a more fine grained fashion i guess
17:29 ngcortes:->jf
17:36 abhinav__: vsyrjala thanks, we will post it in drm_dp_helper and see how things work
21:58 KungFuJesus: mairacanal: were you able to reproduce that crash?
22:36 mareko: gerddie67: hi, are you able to bisect where virgl is failing this? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27494 also, any idea why it's failing?
22:59 karolherbst: jenatali: any further comments/replies to https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23775 ? I kinda want to land it, becasue it fixes things
23:01 jenatali: karolherbst: Did I have any comments on that in the first place?
23:01 karolherbst: ohh shoo, wrong link
23:01 karolherbst: jenatali: I meant https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27385
23:02 jenatali: 🤷‍♂️
23:02 jenatali: I don't really have any opinions tbh. It just seems like all of those bitfields are set by gather_info
23:02 karolherbst: only some are
23:03 karolherbst: I think it makes sense to move it into gather_info, but then I think it's better to move everything in one go and not Cc: stable
23:03 jenatali: Fair enough
23:04 karolherbst: the patch is just to match GLs lowering and it was only added to radeonsi and I think that's the reason why the non deref variant doesn't have it anyway
23:04 karolherbst: so yeah.. probably want to clean it up