06:11glehmann: dj-death: I would like to merge https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/42882 today because of the branchpoint, did you find some to look at the vk commit?
07:26dj-death: glehmann: I did
07:26glehmann: thanks!
12:15karolherbst: can we port away from getopt 🙃 though I guess nobody came up with an interface that's slightly less terrible
12:20daniels: clap?
12:20karolherbst: oh I meant for C code
12:20karolherbst: just having to add 32 bit compilation support for mesa-clc and it's kinda weird
12:20karolherbst: the getopt_long interface I mean
12:21karolherbst: but I think I figured it out how to do that nicely still
12:38MrCooper: karolherbst: looks like "rusticl/meta: add builtin kernel support" broke the build when the mesa-clc option isn't set to "system", since prog_mesa_clc isn't defined then
12:38karolherbst: yeah there is already an MR for it
13:12karolherbst: need a review for mesa_clc here: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/42948/diffs?commit_id=a0d8cf37d0e1f3cc83e7ab6b9fb67fafa9c92476
13:43alyssa: karolherbst: getopt was the less terrible one (:
13:47alyssa: dcbaker: so I bisected...
13:47alyssa: cbc1ec206d5 ("intel: Add support for madvise purgeable VMAs in Xe KMD") is the guilty commit
13:48alyssa: Presumably updating my kernel when moving to f44 uncovered that yesterday
13:48alyssa: but that commit isn't in 26.1 so it wasn't noticed in f44 out-of-the-box
13:49alyssa: madvise has only ever caused me pain on other driver stacks, so, i'm kinda unsurprised
13:49alyssa: zehortigoza: ^
13:50alyssa: glmark2-es2 -bterrain reproduces up to a 50% performance drop from that commit on LNL
13:55alyssa: On top of upstream/main, 1 line patch to unset has_madvise_purgeable improves the terrain fps from 795 -> 1270
13:55alyssa: IOW, 37% of frametime is going to madvise overhead
13:57alyssa: I don't think this is fixable. madvise() is an inherent badly interface.
13:57alyssa: alloc_bo_from_cache() is stalling on madvise calls
13:58alyssa: Nothing is actually get purged here, it's just the ioctl() to mark as purge is slowing things down
14:16alyssa: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/42952
14:22karolherbst: alyssa: figures 🙃 anyway, I figured out how to use long only flags with it.. unless you want the 32bit flag to also have a short variant in mesa_clc
14:25alyssa: karolherbst: -5 it's log2 easy to remembet right???
14:25alyssa: "remembet" ("I hear you like Hebrew letters")
14:25karolherbst: soo.. I was considering it...
14:26karolherbst: or rather.. what's ASCII 32 again?
14:26karolherbst: ahh 32 was a space
14:26karolherbst: that's also cursed
15:32jenatali: alyssa: FWIW looking at the madvise stuff from an outsider, it seems like it would be fine if you just added user space delays/caching to avoid hitting it with high frequency
16:22alyssa: jenatali: Unfortunately that defeats the purpose of madvise
16:22alyssa: which is to workaround Android silliness
16:22alyssa: which feels irrelevant when Android is all-in on angle now
16:23zmike: ~~why not just delete android~~
16:23jenatali: Ah
16:23alyssa: they want "you change apps and all the cached BOs go away instead of holding on to 1 second worth of BOs that never get free because the process is put to sleep so there's not oppportunity to reclaim"
16:23glehmann: must be legacy garbage, otherwise it would be called fmavise
16:23alyssa: to which the answer is of course "this is ridiculous"
16:24alyssa: Like I'm convinced for desktop it's wholly the wrong mechanism but yeah
16:25alyssa: there's a reason that amd/nvidia don't do it
16:26jenatali: Ahh yeah ok that makes sense. The Windows solution to that problem was a notification sent to the app process, and then they call Trim() / Offer() / Evict() on a whole bunch of stuff
16:57alyssa: jenatali: Yes, that would work. Unfortunately Linux uAPIs don't really do notifications and so here we are.
16:58alyssa: I don't know any technical reason it /couldn't/ be done, but it isn't.
17:02pixelcluster: imho you shouldn't need notifications for this
17:02pixelcluster: :)
17:03pixelcluster: generally i'm in more of a priorities believer
17:04pixelcluster: userspace responding to notifications for memory pressure can be ok as an enhancement i'd think, but i wouldn't want to rely on it for the basic behavior
17:05pixelcluster: from a quick look the purgeable stuff isn't much of an issue conceptually, what probably kills it is the fact that it has to do a separate ioctl for every. single. va. range. to. purge.
17:07pixelcluster: (if you conceptualize madvise as basically "priorities but there's only two" it's basically the same)
17:09pixelcluster: hm actually no nevermind that
17:10pixelcluster: syscall overhead itself may not be that bad
17:11pixelcluster: i guess madvise is just heavy for some reason, setting a priority really shouldn't be
17:15alyssa: pixelcluster: the problem is putting syscalls in the BO cache hit hot path
17:15alyssa: It's possible the kernel impl is also slow but I'm not ocmpiling linux to find out
17:17karolherbst: jasuarez: any idea what I can do about the rpi system clock thing resetting on each reboot? It prevents me from updating the Fedora install and was wondering if you have any ideas...
17:17pixelcluster: alyssa: ah yeah
17:18pixelcluster: cool, the one case where i'd say a notif would actually be a good idea
17:21jasuarez: Never got that issue though I'm not using fedora on rpi...
17:24jasuarez: karolherbst: could be that systemd time sync is disabled?
17:25karolherbst: jasuarez: yeah.. I think it's crony based here, I'm reading up on workarounds and using systemd-timesyncd is one of the mentioned one.. trying that
17:25karolherbst: *chronyd
18:04karolherbst: anyway.. moving to systemd-timesyncd fixed it
21:18Kayden: I should have just NAK'd madvise coming back and dropped it from i915.ko backends
21:29alyssa: It's not too late