07:54 Company: is there a portable way to poll() a GLSync? glClientWaitSync() needs the context current, so I can't do it in a thread and peeling the fd out of it isn't portable
08:01 airlied: no
08:15 MrCooper: Company: don't see anything in the spec about eglClientWaitSync requiring a current context
08:16 MrCooper: it even talks about multiple threads waiting in parallel
08:16 Company: I didn't even know EGL has sync variables, too
08:18 MrCooper: ah, I thought you were talking about the EGL stuff :)
08:18 Company: I've been looking into adding some some gsk_renderer_render_async() API so that we don't block until the GPU is done
08:19 Company: (for the public API, we don't block for rendering to the screen)
08:19 Company: is rendering to images
08:19 Company: *ie
08:21 Company: but that still doesn't solve Windows or Mac, because we don't use EGL there
08:52 dj-death: eric_engestrom: there is no more 25.3 planned release?
08:54 eric_engestrom: dj-death: dcbaker was the one handling 25.3, but since 26.1 is out, the normal schedule is to not do another release of the previous cycle anymore
08:54 eric_engestrom: short answer: no :)
08:54 dj-death: okay
08:54 dj-death: just wondering if I need to backport stuff
08:55 eric_engestrom: https://docs.mesa3d.org/release-calendar is usually accurate (although sometimes there are issues merging a change and it doesn't get updated right away)
11:45 tomba: Hi! Could a maintainer ack/merge https://lore.kernel.org/all/20260128-xilinx-formats-v8-0-9ea8adb70269%40ideasonboard.com/ ?
14:36 zmike: mareko: you probably want to review https://github.com/KhronosGroup/OpenGL-Registry/pull/678
14:53 dolphin: drm-tip has unresolved merge conflicts in xe side, I've pinged thellstrom_ so it'll be sorted out eventually
14:56 robclark: sima, airlied: Is there a drm position on kms-only devices exposing driver specific ioctls? (Some do, but I guess that is legacy?) (Re: `drm/msm: restore GEM-related IOCTLs for KMS devices`)
15:08 robclark: also, vaguely related.. I noticed external dma-buf import only de-dups at the drm_file/handle level, so you could still have multiple GEM objs with same underlying dma_resv without driver realizing this (ie. not the gpuvm special case for non-shared BOs).. not sure if this was intentional. It's _probably_ ok because we skip externally allocated BOs in shrinker. But seems like there could be some sharp edges.
15:18 jannau: robclark: asahi downstream uses kmsro in production but shouldn't applications use the GPU only render node for BO allocations
15:21 emersion: robclark: primary nodes are not guaranteed to be openable by non-compositors
15:21 robclark: yes, that is kinda my point (allocate from gpu) :-)
15:21 emersion: and display-only only has a primary node
15:22 emersion: hm, so you mean a driver specific ioctl on the render-only node?
15:22 robclark: hmm, I thought kms-only still ended up with render nodes
15:22 mlankhorst: robclark: shouldn't drivers mostly handle the deduplication and realise same-driver import still?
15:22 emersion: I'd say the "right way" to fix this is to expose a dma-heap
15:22 emersion: and expose a link to the heap from the KMS device
15:23 robclark: dma heaps was were I ran into the duplicate gem's, fwiw
15:24 robclark: I'd prefer giving the gpu a chance to allocate w/ SCANOUT flag.. since at least in this case the GPU knows how to allocate something things the display can import
15:25 robclark: mlankhorst: the issue isn't re-import of something driver allocated in the first place.. _that_ gets de-duped.. the issue is when it is allocated elsewhere (like from dma-heap)
15:31 robclark: ok, I've managed to page back in the issue w/ evil-twin dma-buf imports.. vm_bind (for ex) adds DMA_RESV_USAGE_KERNEL fence so pinned BO isn't unpinned while waiting for vm_bind job to run.. but that deadlocks with resv lock being acquired in the dma-buf import path. We can use _BOOKKEEP instead for imported BOs (since shrinker skips them), but that seems a bit ugly
15:33 emersion: robclark: so the render side can be mixed and matched with multiple display drivers but still knows how to allocate for scanout?
15:34 robclark: practically speaking, yes
15:34 robclark: at least by virtue of there being limited #s of permutations :-)
15:37 MoeIcenowy: BTW something talked here a few days ago -- there's currently no standard IOCTL for allocating display buffer for non-linear buffers
15:38 robclark: I'm kinda leaning towards "there shouldn't be one"
15:38 MoeIcenowy: robclark: if so, this is a reason for device-specific ioctl for KMS nodes
15:39 robclark: ie. try allocating from gpu w/ modifiers the kms supports, and then try to import into display
15:39 MoeIcenowy: BTW for "I thought kms-only still ended up with render nodes", I think currently whether a render node is present is decided on a per-driver basis?
15:39 MoeIcenowy: instead of per specific device
15:40 MoeIcenowy: robclark: however the GPU may allocate uncontingous buffer that KMS device cannot consume
15:40 emersion: robclark: then you can enhance the existing render alloc ioctl for scanout?
15:40 emersion: like desktop GPUs
15:40 robclark: that is already there
15:40 MoeIcenowy: I still think the scanout buffer shouldn't be allocated by render device in renderonly case
15:41 emersion: it's not great for sure
15:41 emersion: hm, then I dont really understand the problem you're trying to solve
15:42 emersion: is this a mesa internal problem, specific to the way the renderonly framework is designed there?
15:43 robclark: well, the initial question is the patch on list I mentioned which is adding back msm ioclts to a kms-only device (there is a modparam for msm that will make it show up as two devices).. the related question is a general issue w/ dmabuf imports not being de-duped causing deadlock possibilities (which is side-stepped if you allocate from the gpu in the first place)
16:11 mlankhorst: robclark: ah that explains, thanks. :) It's still possible to check if the driver already imported the BO though, but a bit more work
16:25 mlankhorst: Go through all attachments, check if attach->ops == own_ops and then priv->dev == dev
16:30 robclark: yeah, I was just expecting core to do this for me... until I dug in and remembered how it worked again
16:32 mlankhorst: Yeah that only works if attach ops are set
17:51 soreau: bluetail: well I just rebooted after uptime == day7, but I have not had a single gpu reset since adding those amdgpu kernel options you suggested
17:52 soreau: I'll complain loudly if I do have another reset, though ;)
18:15 bluetail: soreau good to hear. I wish other things were so easy. Can't yet use amd gpus in proxmox properly. That'd need to be a modern fire-hazard nvidia :/. Or maybe not at all. Bare-Metal has some benefits. Though I absolutely miss the snapshots. Especially since (paid) Macrium Reflect failed me recently, I switched over to (free) Hasleo [...]
18:19 soreau: Free SGTM :-)