06:12 Lynne: how large is the overhead on vkimageview creation? just a malloc in most cases?
06:16 airlied: malloc + surface creation calculations
06:17 airlied: radv makes two descriptors per plane
07:28 slattann: Test Msg
09:22 Lynne: I kinda wanna see khronos work on an mpeg4 decoding extension
09:23 Lynne: that'll keep them busy for at least a year talking about all the corner cases in meetings to produce something that'll really only work on a single vendor
09:29 mlankhorst: which mpeg4? :-)
09:32 Lynne: part 2
09:33 mlankhorst: Usch..
12:38 sravn: tzimmermann: I looked into cleaning up drm_crtc_helper.h. This required me to push a few includes to a lot of files. I wonder how to split it up. With 300+ files touched it is almost every drm driver.
12:38 tzimmermann: sravn, i made such a patchset today
12:39 tzimmermann: but 300 files?
12:39 tzimmermann: that feels a lot
12:39 sravn: drm/drm_modeset_helper_vtables.h is used in many places, but few includes it. Likewise for drm_atomic_state_helper.h
12:40 sravn: I will try to split the mechnical changes in a few larger chunks, split only for review purposes.
12:41 tzimmermann: yeah, i noticed that some atomic-helper headers similar to crtc_helper.h
12:41 sravn: And then the actual header simplification in a few smaller patches.
12:41 tzimmermann: sravn, did you clean up the atomic_header as well?
12:42 tzimmermann: i'm close to sending out my patchset, actually. but it seems that you have a lot more changes
12:42 sravn: drm_atomic_helper.h, drm_crtc_helper.h and drm_print.h
12:42 tzimmermann: my git-diff --stat says 94 files changed
12:43 tzimmermann: sravn, my suggestion is: i send my patchset for crtc_helper.h. you rebase on top. and we mutually review changes ?
12:43 sravn: tzimmermann: deal
12:44 tzimmermann: ok :)
12:44 tzimmermann: give me another hour, at most
12:44 sravn: I am still at work, so no time until tonight.
12:45 sravn: I think my patch exploded because I included drm_atomic_helper in the same go.
12:53 tzimmermann: sravn, could be. here's how i did it: (1) i removed all unnecessary includes from crtc_helper.h. then i built all of DRM and added includes where necessary. this gave me single patch per affected driver. (3) i removed all include statements for drm_crtc_helper.h. I built all of DRM and added back those includes that are really necessary. this gave me another set of pre-driver patches. (3) i squashed all per-driver
12:53 tzimmermann: patches into a single patch for each driver. (4) moved the changes to drm_crtc_helper.h last, so that the intermediate states also build.
12:53 tzimmermann: that was a bit of work, but the end result looks good
17:58 jekstrand: fsign is dumb
18:03 zmike: 🙏 words 🙏 of 🙏 wisdom 🙏
19:04 linkmauve: Some days after boot (atm 19 days), my RSS is filled much more than I would expect from the few programs I have running, it is close to 2 GiB with just a TTY and shell and htop running, all services stopped.
19:05 linkmauve: I see no hungry process in htop, there is nothing in a tmpfs, etc.
19:05 linkmauve: So I am thinking it could be caused by the kernel.
19:05 linkmauve: What can I do to debug that kind of memory leak?
19:06 linkmauve: It also makes my games much more stuttery, and according to perf it is caused by zram swapping of pretty much every process involved, due to being short on RAM.
19:06 linkmauve: I of course have tried swapoff, but that didn’t help.
19:07 ajax: /proc/sys/vm/drop_caches ?
19:08 linkmauve: Writing 3 into that file didn’t help much.
19:09 linkmauve: According to htop, it isn’t caching but actual RSS.
19:11 anarsoul: linkmauve: check /proc/meminfo?
19:16 linkmauve: anarsoul, Slab and SUnreclaim are close to the amount of used RAM I expect to be leaking.
19:17 linkmauve: Slab: 2476876 kB, SUnreclaim: 2400728 kB
19:17 anarsoul: then check /proc/slabinfo?
19:19 linkmauve: Hmm, the biggest one looks to be vmap_area, with 35606237 active_objs of size 64.
19:22 linkmauve: I tried to start Firefox to search what is the slab and how to debug that further, but since I disabled zram it OOM’d my whole session. :(
21:36 jekstrand: Ugh... Who made libmesautil depend on gallium?!?
21:37 jekstrand: It's zmike.... :-/
21:38 jekstrand: Why was this moved?
21:38 jekstrand: It's not usable outside gallium. It depends on all sorts of pipe_* stuff.
21:41 airlied: jekstrand: depends on includes or symbols?
21:48 jekstrand: symbols
21:49 jekstrand: https://gitlab.freedesktop.org/mesa/mesa/-/issues/8098
21:49 jekstrand: It's causing me headaches in NVK
21:52 airlied: yeah the indices stuff should just be in core mesa, unless dozen or something needs it
21:53 jenatali: Nope, we couldn't do CPU readback translation in dzn, we'd do a compute shader instead
21:54 jenatali: (Which is really something that the mesa indices stuff should support doing too, but oh well)
21:54 jekstrand: We should have just not moved it.
21:54 jekstrand: Let me see if I can move it back
21:55 jekstrand: It's fine for mesa/main to depend on gallium at this point. It's a circular dep but harmless.
22:11 jekstrand: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20734