02:35 airlied: mlankhorst: okay on the list now + xe changes, please consider reviewing some of the gaps
07:10 bbrezillon: mripard: not too sure who to ask, so I'm asking you (you'll probably know who to redirect that to). Could you, or another code-drm dev, have a look at patches 2-4 in https://lore.kernel.org/dri-devel/20251015160326.3657287-1-boris.brezillon@collabora.com/ to make sure the core changes are acceptable/make sense.
07:16 bbrezillon: *core-drm
08:05 mripard: bbrezillon: it's more in tzimmermann's alley, but I'll have a look
08:06 tzimmermann: mripard, bbrezillon ?
08:06 mripard: tzimmermann: oh, you just joined, sorry
08:06 tzimmermann: yeah
08:06 mripard: https://oftc.catirclogs.org/dri-devel/2025-10-16#34717573;
08:07 tzimmermann: i see. i'll take a look as well
08:18 mripard: bbrezillon: aside from the enum (and thus the API of the sync callback), it looks good to me
08:33 tzimmermann: i kind of shot it down, TBH
09:36 mripard: sima: I'm not sure if you had the chance to look at https://lore.kernel.org/all/20250902-drm-state-readout-v1-0-14ad5315da3f@kernel.org/, and https://lore.kernel.org/all/20250902-drm-state-readout-v1-10-14ad5315da3f@kernel.org/ in particular?
09:37 mripard: in general, it feels not great, but I'm not entirely sure how to go from there
09:38 sima: hm, what's your concern?
09:39 glehmann: dcbaker: did you forget the 25.3-rc1 announcment email?
09:53 sima: mripard, I have some thoughts on what feels a bit clunky, but reading the thread I don't really understand where you see the raw edges?
11:17 mripard: sima: collecting all the individual states in the old states, and then moving the states to the devices. The state comparison code later on also makes it a bit messier
11:18 mripard: because iirc, you wanted to set them into the old states for that comparison, but we can't really remove the old state of a committed drm_atomic_state, because it's what you're supposed to free
11:20 mripard: so we end up allocating two drm_atomic_state, the old one that got committed, and then whatever we read out, and comparing the new state of the first to the old state of the second
12:14 sima: mripard, hm yeah that's also what I've found a bit awkward
12:14 sima: I have some ideas to toss in for your consideration, will write them up
12:15 sima: but probably tomorrow, today I'll head out soon for a concert in zürich
12:15 sima: mripard, I think conceptually your approach is cleaner than what I've proposed, just a bit messy in the resulting code, and I have some ideas for that part
12:17 mripard: sima: awesome, thanks :)
12:18 mripard: and enjoy your concert
12:24 sima: mripard, well I also need to ponder my ideas a bit more first, they're not that well-baked yet :-P
13:45 mripard: mlankhorst: ping for the drm-misc-next PR
14:17 bbrezillon: tzimmermann: okay, so after a few attempts to implement ::sync() in drivers not relying on drm_gem_shmem, it doesn't really buy us anything, because the sync logic needs to go back to the driver specific gem_object to extract the sgt, etc. Since those drivers already hand-roll their dma_buf implem, there's not much to be saved
14:18 bbrezillon: one extra driver where this hook can be used out-of-the-box is pvr
14:18 bbrezillon: because they support CPU-cached-mappings, and there's nothing preventing the driver from exporting those, AFAICT
14:25 bbrezillon: frankbinns: ^, plus a branch https://gitlab.freedesktop.org/bbrezillon/linux/-/commits/pan-cache-ops?ref_type=heads containing a patch on top of https://lore.kernel.org/dri-devel/20251015160326.3657287-1-boris.brezillon@collabora.com/ to hook this up in PVR
14:27 bbrezillon: but maybe all of this is moot if we assume BO exported by simple GPU drivers will never be imported by other drivers, or, when they are, are never CPU-accessed. Dunno
14:30 frankbinns: MTCoster: ^^
14:35 daniels: bbrezillon: those are two load-bearing assumptions which ... don't bear much load
14:36 mripard: daniels: so that's what architecture is about?
14:39 bbrezillon: daniels: I mean, pvr has been living on these assumptions until now, and if I read MSM code correctly, so has freedreno :-)
14:39 daniels: mripard: my civil-engineer friends keep on telling me that software engineering is not real engineering. not sure what they mean tbh.
14:39 bbrezillon: :-)
14:46 mripard: daniels: is it really engineering if you don't get a ring and swear an oath though? :)
14:48 daniels: dunno, I dropped out after about half an hour
14:52 MTCoster: I had to explain to someone the other day why I'm bothering to go back to school for engineering when I'm already a software engineer, that was a fun conversation
14:53 MTCoster: bbrezillon: just on my way out the door for the day right now, I'll check this out tomorrow
14:53 bbrezillon: no worries, it can wait
16:04 dcbaker: glehmann: No, I ended up starting the process right as I went to bed, so the announcement is going out this morning :)
17:13 phasta: Ahm, does dim from maintainer-tools sometimes add a Fixes tag?
17:14 phasta: I swear it did add one, and a wrong commit..
22:11 anholt: jnoorman: haven't been able to focus on anything hard today thanks to the early morning assembly meeting, but you (and others doing fossil-db work) might enjoy this: https://gitlab.freedesktop.org/mesa/shader-db/-/merge_requests/117
22:53 idr: anholt: Whoa! That's pretty frickin' cool!
22:54 idr: On a machine with lots of cores, the time used to report the data is a substantial percentage of the time taken to collect the data.
22:55 idr: On my 64c/128t machine... I think it takes 18-ish minutes to run all the fossils, and 2 to 3 minutes to report the data. That's... ridiculous.
22:57 anholt: yeah, I was at 15/2.5 for turnip reports. (the ones cited in the commit message are fast because we've got an assert fail that's crept in mid-way again)
22:58 anholt: need to rig up shader-db-private in pre-merge CI for folks that are part of that group.
22:58 anholt: (though, can't really do that with those runtimes, really)