00:26 zmike: awesome work guys
09:53 MrCooper: DemiMarie: my understanding is yes in principle, though anything which can be represented as a dma-fence must have a timer or other mechanism which ensures that the dma-fence is signalled within reasonable time
10:00 pinchartl: emersion: you've reviewed "[PATCH] drm/fourcc: Add RGB161616 and BGR161616 formats" (20240226132544.82817-1-jacopo.mondi@ideasonboard.com). do you plan to push it to drm-misc ? I'm unsure what the rule is regarding pushing core changes to drm-misc. do we need a R-b from any DRM contributor, from a drm-misc maintainer, or from a DRM maintainer ?
10:01 pinchartl: we can push it too, once we know what the rule is :-)
10:01 pinchartl: sima: ^^
10:02 pinchartl: mlankhorst: ^^
10:02 sima: https://drm.pages.freedesktop.org/maintainer-tools/committer-drm-misc.html#merge-criteria
10:03 sima: and ack is sufficient
10:03 pinchartl: thank you :-)
10:03 sima: I mean best judgement and all that applies, maybe don't push really gnarly locking rework with just a cursory ack :-P
10:04 pinchartl: yes, the usual common sense rule of not gaming the system
10:07 sima: pinchartl, jmondi this reminds me of the other discussion of formally adding libcamera to the list of userspace apis/libraries than can ask for drm_fourcc.h allocation
10:08 sima: not sure what happened to that idea?
10:09 sima: I think a handful of acks from the community would be good, just to sign off on this direction
10:09 pinchartl: Jacopo sent patches and things died out I think
10:09 pinchartl: we can respin that
10:10 jmondi: sima: do you mean https://lore.kernel.org/all/20240228102245.80469-2-jacopo.mondi@ideasonboard.com/T/
10:13 emersion: pinchartl: my understanding is that maintainer ACK is not strictly required
10:14 emersion: but better ofc
10:14 pinchartl: emersion: who are the official maintainers for 4CCs ?
10:14 emersion: DRM?
10:15 pinchartl: is that Sima and Dave, or Maarten, Thomas and Maxime ?
10:15 pinchartl: it sounds like one of the areas that are collectively maintained
10:15 sima: pinchartl, yup, just missed it
10:15 pinchartl: everybody is responsible for them, so nobody does anything :-)
10:16 emersion: i think that falls into "DRM DRIVERS AND MISC GPU PATCHES"
10:16 sima: yeah
10:17 pinchartl: ok, so strickly speaking, Thomas, Maarten and Maxime
10:17 emersion: formally, what does "reviewed" or "acked" in the maintainer-tools docs mean?
10:17 emersion: maintainers, committers, contributors, or anybody>?
10:18 emersion: i've assumed "committers" so far
10:18 sima: emersion, it's all a bit a judgement call
10:18 emersion: yeah, i suppose it depends on the patch ofc'
10:18 sima: which is why we link to the more in-depth discussion for drm-intel
10:18 sima: that tries to answer this kinda unanswerable question a bit at least
10:19 sima: since the real rule is that if you merge it and there's immediate screaming, it wasn't enough reivew
10:19 emersion: pinchartl: you have drm-misc push access right?
10:19 sima: emersion, daniels, airlied https://lore.kernel.org/all/20240228102245.80469-2-jacopo.mondi@ideasonboard.com/T/ maybe ack from you too, should cover enough of the gl/vk/drm side?
10:19 sima: pinchartl, and yours and then it's imo good
10:20 sima: but you can go fish for more ofc :-)
10:21 emersion: sure, ack
10:23 pinchartl: emersion: yes
18:05 DavidHeidelberg: is possible that Mesa doesn't implement any (EGL) display extension ?
18:08 DavidHeidelberg: I wondering after this [1] EGL spec change, where would we put display extension. We have dislay extension EGL_KHR_get_all_proc_addresses, but we handle it as client extension... [1] https://github.com/KhronosGroup/EGL-Registry/pull/199/files
18:16 daniels: DavidHeidelberg: every extension which isn’t the EGL_KHR_platform_* is a display extension
18:16 daniels: so yeah, loads
18:17 DavidHeidelberg: so does that mean, they're reported same way as the client extensions?
18:18 DavidHeidelberg: what I'm wondering after this spec change, what has to be changed on the Mesa side, eventually on GTK/Firefox side
18:19 daniels: on the users - they’ll discover it through eglQueryString(dpy, EGL_EXTENSIONS) with a real dpy, not EGL_NO_DISPLAY
18:24 daniels: just looked at the MR and it shouldn't be added to ClientExtensionString in src/egl/main/eglglobals.c
18:25 DavidHeidelberg: right, I got to that conclusion, since glvnd will filter it ;)
18:25 daniels: add an _EGL_CHECK_EXTENSION() case to _eglCreateExtensionsString
18:26 DavidHeidelberg: thanks!
18:27 daniels: np
18:29 DavidHeidelberg: I think now we're ready to go in, as it'll pass all the tests
18:29 DavidHeidelberg: if you have chance to drop the A/R-b on the MR (or at least the particular commit with this change after I test it locally, I would be very grateful)
18:30 zmike: \o/
19:10 zmike: DavidHeidelberg: there's already a solution: -Dintel-rt=disabled
19:10 zmike: :D
19:11 DavidHeidelberg: sounds good to me, but I'll keep the issue opened up :P
19:11 DavidHeidelberg: thanks
19:14 DavidHeidelberg: extension seems to be reported now after the change :) just need to adjust GL-CTS to account for that
19:15 Company: DavidHeidelberg: GTK doesn't use select_group, it just checks the default list of configs and discards all the ones without an RGBA visual
19:33 DavidHeidelberg: Good then, so only place where it's checked is likely GL-CTS
19:47 derr: 2/Quit
20:06 gfxstrand: eric_engestrom: How long do we have before 24.1 final? I kinda want to get modifiers in for NVK.
20:17 daniels: please …
21:23 DavidHeidelberg: eric_engestrom: any patches u may want to apply to CTS? I'll be pushing https://gerrit.khronos.org/c/vk-gl-cts/+/14636