08:14 llyyr: https://cgit.freedesktop.org has an expired SSL cert
08:14 llyyr: probably not used much often, but I followed URL from 2014 expecting to see a commit...
08:17 hakzsam: dcbaker: please make sure to cherry-pick https://gitlab.freedesktop.org/mesa/mesa/-/commit/0d9d45db4e1b6d00747bf635ba3222146a899468 for 25.3.0, thanks
09:59 rcv11x: Hello, is there still no news about 25.3? The date shown on the Linux calendar has already passed 😅
10:06 llyyr: rcv11x: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38432
10:06 llyyr: it'll be done when it's done :shrug:
10:08 Company: yeah, someone figured out that all GTK apps are broken, so nobody hurries a release until that's guaranteed to be fixed
10:12 llyyr: yeah that's me (the person breaking them was also me)
10:22 rcv11x: @llyyr Great, what does that link mean? Are you already preparing for the launch? Sorry for asking, but I'm more used to GitHub than GitLab and I'm not very familiar with this.
10:23 llyyr: that's the MR for merging cherrypicked changes from main to the release branch
10:23 llyyr: once that's merged the only thing left is actually releasing (and everything else that entails)
11:17 rcv11x: @llyyr okey thanks for the info
12:58 mlankhorst: tzimmermann: Hmm did something go wrong? I thought I did tag it
12:59 tzimmermann: mlankhorst, no nothing wrong. i just need to know if i need to do a cherry-pick into drm-misc-next-fixes
12:59 mlankhorst: I created a pull request I thought, let me check what happened
13:01 mlankhorst: I'm going crazy I think
13:01 tzimmermann: no PR?
13:02 mlankhorst: Can't find it here somehow, let me retry making it real quick
13:02 tzimmermann: the last one i've seen was from Nov 05
13:02 mlankhorst: weird, should have been the 11th or 12th
13:03 tzimmermann: mlankhorst, the last tag i see is drm-misc-next-2025-11-05-1
13:04 mlankhorst: I think I did complete the summary, but forgot to send it. Let me create a new one real quick!
13:05 mlankhorst: Found my old TAG_EDITMSG fortunately
13:06 tzimmermann: mlankhorst, i have a patch that needs to go with it:
13:06 tzimmermann: 0709abaf6734 ("drm/imx/ipuv3: Fix dumb-buffer allocation for non-RGB formats")
13:07 tzimmermann: brb
13:10 mlankhorst: tzimmermann: gotta be quick to cherry pick, I only had to add a summary for the nouveau changes. :-)
13:10 tzimmermann: that patch is already in drm-misc-next
13:10 tzimmermann: from yesterday
13:11 mlankhorst: Ah yeah I see
15:04 bbrezillon: tzimmermann: Hi, I was trying to rebase digetx's shmem-shrinker patchset (https://patchwork.kernel.org/project/dri-devel/patch/20240105184624.508603-1-dmitry.osipenko@collabora.com/) today, and while doing that, I noticed the ivpu accel driver started touching drm_gem_shmem_object internals in a way that makes our life harder to control lifetime of backing storage (pages and sgt,
15:04 bbrezillon: basically)
15:05 bbrezillon: digetx mentioned that you considered forking drm_shmem at some point to start from a clean slate, and I start thinking this might actually be a sensible way to approach it
15:07 bbrezillon: is this still something you're okay with or should I push harder on my attempt to fix those drivers and hide more of drm_gem_shmem_object internals so we don't end up in the same situation in the future?
15:20 tzimmermann: bbrezillon, dunno. my idea was to make a blackbox-version of gem-shmem for all those simple drivers that do not touch the internals. i'm not sure whether that is a good idea TBH. if you could rebase on top of the existing gem-shmem, i think this would be better
15:21 tzimmermann: maybe the ivpu driver could fork its own copy of gem-shmem
15:22 tzimmermann: and we'd revert the related changes from gem-shmem, so that it becomes more blackbox-y again
15:22 bbrezillon: tzimmermann: that's exactly what I want, a version that hides all internals to remove any temptation to abuse fields that are normally controlled by the drm_shmem layer
15:24 bbrezillon: even for drivers that need advanced control on drm_gem_shmem internals, it'd be way easier to maintain through a set of advanced helpers than letting drivers do what they want with those fields
15:29 digetx: forking gem-shmem to gem-shmem2, making drivers one-by-one to use gem-shmem2 and sunsetting old gem-shmem in the end would be a painless approach; I'd suggest to proceed with the forking if you're okay with it tzimmermann
15:32 tzimmermann: what about the existing drivers that extend gem-shmem (panfrost, lima)? would they internalize a copy of gem-shmem?
15:32 digetx: they will move to gem-shmem2
15:33 bbrezillon: tzimmermann: we probably need to keep some bits exposed
15:33 bbrezillon: for the container_of() trick to work
15:36 bbrezillon: but we can, for instance, move everything related to pages/sgt and their refcounting to a drm_gem_shmem_backing object that's defined in drm_gem_shmem_object.c, with drm_gem_shmem_object having a pointer to this struct
15:39 digetx: not sure I'm following, I was thinking about a complete fork of drm-shem code, not parts of it
15:41 bbrezillon: I think tzimmermann's point is that you can't really make it a blackbox because of how inheritance works right now
15:42 bbrezillon: panfrost_gem_object embeds a drm_gem_shmem_object, so it needs to know its size (and thus see its definition) for it to work
15:42 digetx: see, thx
15:42 tzimmermann: yeah, this
15:43 bbrezillon: there are potential trics to make it work
15:44 tzimmermann: if all these drivers internalize a copy of gem-shmem, gem-shmem can be a blackbox
15:44 tzimmermann: but then we'd have lots of duplicated code in drivers
15:44 bbrezillon: one of them being to add a drm_gem_shmem_object_alloc() taking the driver data size, and returning a pointer to this section (with drm_gem_shmem_object being placed just before)
15:45 tzimmermann: so my proposal is to try harder to integrate the shrinker with ipvu
15:45 tzimmermann: OR internalize gem-shmem only into ivpu
15:45 tzimmermann: and the rest of gem-shmem would remain as-is
15:46 bbrezillon: I guess i'd be ok to patch ivpu to play with the rules if I had a guarantee this won't happen again
15:46 bbrezillon: unfortunately, with everything being exposed as it it right now, I fear it's going to happen again
15:47 tzimmermann: and workarounds for making thins work can turn out to become a maintenence nightmare. gem-shmem is already confusing in places
15:47 tzimmermann: did you reach out to ipvu devs?
15:47 tzimmermann: maybe they can refactor
15:48 tzimmermann: (i don't have ipvu here, so i can't tell right now)
15:48 bbrezillon: BTW, it's not even the shrinker I want to have working with ivpu, it's just that the way they do it right now gets in the way of better lifetime control of resources attached to gem_shmem
15:48 tzimmermann: urgs
15:48 bbrezillon: which is required if we want a gem_shmem shrinker
15:49 tzimmermann: then let's first see if they can rework.
15:49 tzimmermann: otherwise, if they have to abuse gem-shmem to make thing work, it's better if they internalize
15:50 bbrezillon: sure, but how do we make sure the next driver doesn't do the same
15:50 bbrezillon: I'd really like to give this gem-shmem-internals-as-a-blackbox thing a try
15:51 bbrezillon: because otherwise we'll keep running into these issues anytime we want to add a new feature...
15:51 bbrezillon: I'll probably patch ivpu in the process, and ask them to test/review
15:59 tzimmermann: it's getting late here. i'll look at the ipvu code on monday. let's talk then
16:07 bbrezillon: sure, let's have this discussion on Monday
16:35 dcbaker: hakzsam: I just saw that. The tag you have in that commit doesn't conform to what the script looks for so It didn't show up, we're migrating away from the `Cc` form anyway (which used to actually cc a list) to `backport-to: 25.3`, if there isn't a clear fixed commit. I'll pull that into the 25.3 branch before I release today
16:35 hakzsam: dcbaker: my fault, sorry
16:36 dcbaker: no worries, we should probably do a better job of communicating what those tags should be anyway
19:04 silurian_invader: if you convert a handle to and fd and then convert the fd back into a handle (on the same drm device) are you supposed to get the same handle back?
19:07 silurian_invader: I'm running into a bug where I create a dumb buffer, convert it to an fd, give it to mesa, mesa converts it into a handle and does some work, then mesa decides it's done with the handle and destroys it
19:08 silurian_invader: but the handle mesa destroys is the same one I converted into an fd, so when I try to use the handle again it's no longer around https://paste.debian.net/1408573/
19:11 silurian_invader: do I need to do something special to tell mesa not to destroy the handle?
19:15 anholt: you need to have your own fd and not share.
19:15 silurian_invader: what do you mean?
19:15 anholt: don't try to use the same drm fd that mesa is.
19:16 anholt: reopen if you need to.
19:19 silurian_invader: where does mesa get its fd from?
19:22 silurian_invader: when I initially get the handle I call dup() on the fd
19:22 silurian_invader: so I don't think I am using the same fd
19:24 zamundaaa[m]: dup isn't enough
19:25 alyssa: lavapipe-vkd3d seems to be timing out a bunch, is this a new job?
19:26 cwabbott: I hit that too
19:28 alyssa: yeah I was looking at your MR just now
19:28 alyssa: but I hit it earlier this week I think
19:28 alyssa: doesn't seem to be a new job but seemingly something changed
19:29 alyssa: vkd3d itself was uprevved on Tuesday, maybe that's what changed
19:30 silurian_invader: zamundaaa: how am I supposed to get the path to use with open?
19:31 silurian_invader: read /proc/self/fd ?
19:35 zamundaaa[m]: [@_oftc_silurian_invader:matrix.org](https://matrix.to/#/@_oftc_silurian_invader:matrix.org): there's drmGetDeviceNameFromFd2 for that
20:27 valentine: alyssa: had a quick look, looks like the uprev this week bumped the runtime from around 10min to 15min
20:27 valentine: eric_engestrom: ^^, seems like it's running more tests now
20:28 valentine: ack if someone wants to increase the timeout for now
20:32 alyssa: Oops :(
20:33 silurian_invader: zamundaaa: ok, but this doesn't work because I need to be the master to do atomic modesets, and the fd that I start with is already the master
20:34 zamundaaa[m]: silurian_invader: then give Mesa the fd that isn't drm master?
20:36 zamundaaa[m]: KWin also uses a fd that is master for modesetting, and an authenticated fd for Mesa / gbm to do allocations and stuff with