05:48 <cmeissl[m]> kusma: Is the fix included in 25.2.2?

07:21 <CounterPillow> cmeissl[m]: this is something you can easily check yourself with a git clone of the mesa git repository, `git tag --contains the-fix-commitish-here`

07:46 <cmeissl[m]> CounterPillow: thanks, yes. I already had a look at the commit log (and merge requests) prior to asking, but I haven't found something obvious. I am already on 25.2.2, so I had a look at the main branch. There are one or two commits that mention some leaks, but afaict they reference fixes of commits not included in mesa 25.2.2.

07:46 <cmeissl[m]> I am currently trying to collect some valgrind logs.

07:48 <cmeissl[m]> I will try to take a closer look, but valgrind reports a lot of lost blocks in panfrost_kmod_bo_alloc when using NV12 MTL Tiled, but not with NV12 Linear it seems

07:48 <cmeissl[m]> I did two runs, and the number of lost blocks seem to correlate with the number of video frames (at least more blocks when letting the video run for longer)

08:30 <cmeissl[m]> kusma: thanks for the commit sha. This was one of the more obvious I found :)

15:58 <cmeissl[m]> kusma: valgrind points to `panfrost_kmod_bo_alloc` called from `update_textures` and also `_mesa_DrawElementsBaseVertex`

15:58 <cmeissl[m]> I have set a watch on that specific bo refcnt and it seems it increases over time. The majority of the increases seem to come from `panfrost_pool_take_ref` inside of `panfrost_launch_grid_on_batch` called during `panfrost_mtk_detile_compute`

16:05 <daniels> hrm, I thought one of kusma's commits had fixed that

16:14 <cmeissl[m]> The refcnt settled at around 123/124. I can see a label "Descriptor" on that bo. But I have no idea if I am on the right track tbh.

17:46 <daniels> cmeissl[m]: have you got and/or can you cherry-pick cc66651fc1ea and fb0a422be2e9?

18:35 <cmeissl[m]> daniels: thanks, seems both commits are already included in 25.2.2. but I double checked that the changes are present in the checked out source tree

18:40 <cmeissl[m]> One thing I noticed is that `panfrost_create_sampler_view_bo` might use a different pool for `pan_pool_alloc_aligned` and `panfrost_pool_take_ref`

18:40 <cmeissl[m]> But at least for what I try to find it seems to make no difference.

19:59 <cmeissl[m]> hm, panfrost_pool_take_ref in panfrost_create_sampler_view_bo seems to return the same bo for some time and increase the refcnt to around 123-129 before switching to a different bo where the increase starts over

21:02 <cmeissl[m]> ah, now it makes sense. the mem_pool uses a bo with 4096 bytes as the backing store. so if each frame 64 bytes are requested it will exhaust after ~1s for a 60fps video, allocating another 4096 bo. so this might explain why meminfo shows ~4k per second increase

21:11 <cmeissl[m]> I also saw a lot of 32-byte requests, which would correlate with the ref count of 128 I saw on the bo.