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 :-)
19:47 sima: robclark, hm, I thought that's the "oh we have this dma_buf already" case for?
19:47 sima: unless something broke
19:48 sima: I think there was a case around getfb2 where you could have multiple gem handles, but should still all resolve to one gem_obj
19:49 sima: wrt kms-only ioctl, that's kinda what properties are for
19:49 robclark: so drm_prime_lookup_buf_handle() dedups but only within drm_file
19:49 robclark: so doesn't help when there are multiple drm_file's at play
19:49 sima: the entire allocation pain is kinda unsolved though, but I guess the pain wasn't ever felt badly enough
19:51 sima: robclark, first if in drm_gem_prime_import_dev() is supposed to take care of that
19:51 robclark: I keep telling them to allocate from the gpu, since mesa is the thing that knows what it is doing.. and I have enough problems without inventing new ones :-)
19:51 sima: yeah that's pretty much how you should I think
19:52 robclark: so drm_gem_prime_import_dev() only handles re-importing from same dev
19:52 robclark: ie. drm_gem_is_prime_exported_dma_buf()
19:54 sima: robclark, hm this could very well be a regression from aeons ago when switching from the linked list to the two rbtrees
19:55 sima: chkoenig also broke this in a really strange way that I didn't fully understand until igt complained
19:55 sima: so might just me not understanding the code again
19:56 robclark: hmm, possible.. since my memories were that this was handled _somewhere_.. but things changed since last I looked ;-)
19:56 sima: yeah
19:56 robclark: ok, so we are in same boat :-)
19:56 sima: like if you have a testcase that goes boom, defo trust that
19:56 sima: but if it's just conjecture from reading code I'm betting on it's that really funny cornercase everyone is blind to when reading the code
19:56 sima: but it somehow makes stuff work
19:57 robclark: kinda... the closed driver folks were trying to port to vm_bind.. and are able to trigger a deadlock because of the two-gem-one-resv thing (but they are also allocating shared buffers from dma-heap.. because downstream kgsl doesn't support dmabuf export (because ion)..
19:58 robclark: if we only ever export from drm (and don't have multiple drm devices) everything is fine.. but I _expect_ it to be possible to hit same issue w/ dual-gpu
20:01 sima: robclark, hm yeah I guess then we do have a gap in the handle :-(
20:03 robclark: I don't have the exact stack trace handy, but IIRC somewhere in the dmabuf import path it grabs resv lock vs drive already holding the same lock on a different gem obj pointing to same dmabuf
20:04 robclark: * dmabuf attach path
20:04 sima: ugh
20:04 robclark: or maybe it was a fence wait
20:04 robclark: anyways, it was a path you wouldn't go down if you realized you'd already imported the dmabuf
20:05 sima: hm, that should kinda work I thought
20:05 sima: since double-importing is kinda how userspace figures out it has it already, because it should get back the same gem handle
20:05 sima: or do you mean double import on a different drmfd?
20:06 robclark: right, same dev, diff drm_file
20:06 sima: yeah that might go boom
20:06 robclark: so the workaround at this point is vm_bind_job_attach_fences() to use _BOOKEEP instead of _KERNEL for imported BOs
20:06 robclark: (since the point of _KERNEL there is just to prevent shrinker from evicting.. and shrinker skips imported BOs)
20:07 robclark: but that feels kinda like papering over a problem