02:47 zmike: mareko: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/45456
02:53 HdkR: I love when people fork after greating graphics contexts
02:54 zmike: you like android?
02:54 zmike: out, out!
02:54 HdkR: Oh no, CS2 does it.
02:55 HdkR: It's absolutely abysmal
03:58 airlied: robclark: do I want to know why you added a modparam to stop waiting for fences in the shrinker? :-)
03:58 airlied: or more importantly do you want Christian to notice
04:10 robclark: airlied: it's the steam frame switch
04:11 airlied: lols, do we just evict memory no matter what then :-)
04:11 airlied: where the hell is the steam frame even evicting memory to
04:12 robclark: zram
04:12 robclark: they brought the idea up.. and vrcompositor has fairly unique latency reqs.. so it seemed to me a "let userspace decide it's needs" thing
04:18 airlied: this seems more like let userspace shoot itself in the foot
04:18 airlied: but I haven't dug too deep into it
04:18 airlied: like someone is trying to break the dma-fence rules
04:20 robclark: really it's just trying not to have latency in vrcompositor... the part they have in their kernel that isn't upstream yet is a way to mark vrcompositor's vm as "pls don't evict me".. that and their soln to the thing that matt proposed about reducing locking latency
04:21 robclark: I think modparam is a reasonable way to let it be userspace policy
04:21 cwabbott: afaiu it's "fail rather than wait on fences", not "evict anyway when the job is still running no matter what"
04:21 robclark: right
04:25 airlied: I assume someone check the shrinker ever fires at all in that case?
04:26 airlied: I suppose in theory it should go down an lru and only evict things that aren't fenced
04:26 robclark: that's all still true
04:27 robclark: it's just skipping the more extreme step of blocking once easier options are exhausted
04:27 robclark: vk/vm_bind doesn't give kernel much good options when it comes to knowing what needs to be resident
04:31 airlied: robclark: why isn't that the default? chromeos needs to keep shrinking always?
04:33 robclark: ChOS at least as of when I left goog before the whole android nonsense is still using gl/gallium and bo tracking for everything.. typically for web browser only maybe 30% of BOs need to be resident at any given time and bo tracking gives the kernel that info.. a 4gb chromebook is swapping hard constantly
04:34 robclark: (for everything that isn't roblox and couple of other android games)
06:41 daniels: much of it is VK now, courtesy of ANGLE, courtesy of Android
09:01 pac85: airlied: the wait for the fence in the shrinker happens while holding a lock to the object. When this happens for an object shared between compositor and a game, that object's lock can be held for a whole game's frame which causes vrcompositor to miss several vblanks
09:05 pac85: That's very undesiderable for us. But also, at least what I did in the downstream patch (will review the submission later) was just removing the "active_{evict, purge}" stages. I don't think it makes much difference since the shrinker will be invoked many times until an allocation succeeds, it just means it might take more iterations and that perhaps GPU shrinker behaves less aggressive overall towards running applications
09:07 pac85: airlied: it's not evicting memory no matter what, later evict will check if the object is active and bail if it is, active purge just makes it more aggressive by waiting for the fence while holding that lock so that the later check always passes. There's no correctness issue
09:25 pac85: In general preemption exposed lot's of issues with contention since suddenly it's not all in one timeline anymore and there's concurrent GPU work
09:28 pac85: Holding a lock in the one ring case effectively has the effect of running the shrinker between two submissions which is the intended effect. Holding the lock while there's something else submitting at an higher frequency has a whole new sideffect
12:35 alyssa: danylo1: too sleepy to reply on MR but I think I'm ok with https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/42132 if others are
12:36 alyssa: the diffstat isn't terrible and this is a really creative use of coccinelle
12:36 alyssa: and i'm a *lot* more comfortable with "LLM generates a Coccinelle patch, Coccinelle runs it" than I am with "LLM patches the codebase"
12:37 alyssa: (Maybe that's a silly aesthetic bias and I should get over it, but hey.)
12:38 alyssa: (It does mean we can run your script on-going basis without needing to spend our own tokens on it, so that seems important. I was about to ask "how do we keep this in sync?" then saw the CI patch.)
12:39 danylo: alyssa yeah, I was positively surprised that there were only a few places that needed to be hand-touched
12:39 alyssa: IDK how soon you wanted to merge that and I've kinda spun my wheels for 2 days now on various GitLab activities and was really hoping to get back to writing Jay patches today
12:39 alyssa: But the overall shape of it looks good
12:40 alyssa: (This isn't an a-b, more of a "if this gets merged with someone else's review while I'm on vacation, I won't be offended when I get back")
12:40 danylo: the sooner the better, since we have to carry it in Frame's downstream branch, but also don't want to rush it if there are any objections or questions
12:40 alyssa: right yeah ok
12:41 alyssa: not the worst thing in the deckard tree xd
14:01 fufexan: does anyone know why at least on amd moving from HDR + WCG to SDR + WCG without a modeset seems to mess up colors on OLEDs?
14:01 fufexan: for example someone gets grey blacks, someone else gets a red tint on everything
14:38 MrCooper: fufexan: which display server is that?
14:41 fufexan: both Hyprland and Plasma
17:11 anholt: gfxstrand: do you care to look at the new meson goop I had to do for rust pipe format, or should I hand it off to marge?
19:20 rodrigovivi: airlied: https://gitlab.freedesktop.org/drm/maintainer-tools/-/merge_requests/112
19:21 rodrigovivi: with this change in place, then it would only pick from drm-next to the unified for-linux-next ... and from -rc1 to -rc6 it takes from all branches...
19:21 rodrigovivi: perhaps we should limit to -rc5?