11:15tzimmermann: jfalempe, hi. there's a mgag200 irq fix on dri-devel. if you have a bit, could you please review until Thursday evening, so it can be included in this week's drm-misc-next PR?
12:33jani: tzimmermann: mripard: mlankhorst: ping about https://lore.kernel.org/r/87a5hzxi6b.fsf@intel.com
12:36tzimmermann: jani, sure
12:36tzimmermann: np
12:36jani: tzimmermann: thanks!
12:36jani: imre: ^
13:13imre: jani, tzimmermann, ok, thx
14:38gfxstrand: dcbaker: Does meson have a way I can define my own functions yet?
14:41robclark: idk if anyone has opinions on libdrm build system .. https://gitlab.freedesktop.org/mesa/drm/-/merge_requests/390 .. I'm not hugely a fan of multiple build systems, but it is just replacing one build system that everyone ignores (Android.mk) with another (Android.bp), so I guess meh? If no one objects I will merge it.
14:45pepp: robclark: looks related to !361
14:46robclark: hmm, at least !390 garbage collects the Makefile.sources as well
14:47robclark: also I think I kinda prefer just removing android build support for libdrm_$driver's which aren't really used/tested on android, but don't care strongly
14:50pepp: right, !390 sounds ok then (though I don't know much about Android.mk or .bp)
15:06dcbaker: robclark: the most frustrating thing is that I offered to write a bp backend for meson, or a meson front end for blueprint and Google basically said “no, we just want projects to carry two or three build systems”
15:15pinchartl: airlied: do you plan to attend LPC ?
15:22alyssa: cwabbott: i'm scrolling through the common BVH building code now, one thing that caught my eye is the decoupled lookback prefix sum from radv
15:22priyansurout: hi
15:22alyssa: IIRC, that algorithm relies on vulkan UB, it happens to work on desktop parts but not on apple and arm
15:23alyssa: (why am I always the 2 worst archs..)
15:23cwabbott: alyssa: how exactly doesn't it work?
15:23alyssa: obviously we're a long way out from ray tracing in either hk or panvk, but thought I'd flag it since - if we're going to rely on UB in common code - we should at least document that loudly
15:24alyssa: cwabbott: haven't read the specific radv implementation, but typically decoupled lookback relies on forward progress guarantees (IIRC?) across workgroups
15:24cwabbott: the sorting library we used uses the same algorithm and it supports mali
15:24alyssa: interesting.
15:24cwabbott: alyssa: it actually doesn't really
15:24priyansurout: Hello everyone,
15:24priyansurout: I'm Priyansu Rout from India, currently in my second year of B.Tech in Computer Science and Engineering. I've been working on blockchain projects and now want to gain experience with X.Org, particularly at the kernel level.
15:24priyansurout: I'm interested in becoming a mentee in the X.Org Evoc Mentorship Program. I'd appreciate any advice on how to start contributing to X.Org and how the mentorship process works.
15:24priyansurout: Thanks!
15:25cwabbott: it requires the ability to execute more than workgroup at a time *or* that earlier workgroups are launched before later ones
15:25alyssa: (...I would be very happy to be wrong here, because I'd love to use decoupled lookback for geom/tess on honeykrisp lol)
15:26cwabbott: that's a pretty mild requirement IMO
15:26alyssa: *nod*
15:27alyssa: IIRC, someone found that M1 fails the "earlier workgroups launched before later" property, but does seem to satisfy "workgroups once launched are guaranteed forward progress"
15:27alyssa: and hence implemented decoupled lookback by just dynamically assigning the workgroup ID (with an extra atomicAdd at the start)
15:28alyssa: not sure about Mali, i'm trying to remember where I read this broke on Arm
15:29alyssa: https://users.soe.ucsc.edu/~tsorensen/files/oopsla2021b.pdf I think. Not that I actually read that paper..
15:32robclark: dcbaker: yeah, they seem to not want meson or other 3rd party build systems on their builders... the insane thing is android replaces the linux kernel build system with .bp
15:33dcbaker: robclark: and they couldn’t even use blaze/bazel, a thing projects already have for *checks notes* Google
15:34priyansurout: Is there anyone here who know about the X.Org Evoc Mentorship Program?
15:34robclark: yeah, don't ask me why, idk
15:35cwabbott: alyssa: we could probably make the common code use an atomic under a config or something
15:36alyssa: :+1:
15:37alyssa: I'm not suggesting any changes now, I just flagged it and figure it's worth documenting the assumptions somewhere at least
15:59pixelcluster: alyssa: yes, the PLOC algorithm in general relies on already-launched workgroups not being starved by new/other workgroups
16:00pixelcluster: but I don't think it relies on anything else
16:01pixelcluster: the decoupled lookback thing doesn't rely on other workgroups making progress, although it'd be better for perf if they did
16:01pixelcluster: if the other workgroup hasn't yet computed the result, the first workgroup will also compute it redundantly so to speak
16:08alyssa: pixelcluster: interesting. is that different from the "standard" decoupled loopback?
16:08alyssa: (there's a lot of bad info about prefix summing floating around and i don't know what's right anymore!)
16:09pixelcluster: alyssa: I definitely didn't come up with this, I'm pretty sure I read it in some nvidia paper but I'm also not at all the authority on what is "standard" decoupled lookback and what isn't
16:10alyssa: yeah, *nod*
16:10cwabbott: unfortunately that's not quite true - it waits for the previous workgroup to compute its result
16:10alyssa: the other source of confusion is that decoupled lookback requires vulkan memory model (I think?), which Metal doesn't/didn't have
16:11alyssa: device-scope memory barriers, I mean
16:14alyssa: well, honeykrisp & panvk ahve bigger problems for RT anyway :p
16:16pixelcluster: cwabbott: wdym?
16:16cwabbott: pixelcluster: each workgroup will spin until the previous workgroup's results are ready
16:17cwabbott: not the entire prefix, of course, just that workgroup's partial prefix
16:18cwabbott: so it does rely on earlier workgroups making progress
16:18pixelcluster: cwabbott: it won't exactly spin, no
16:18pixelcluster: it goes backwards over all previous workgroups and looks if they finished
16:18cwabbott: no, it does
16:18pixelcluster: https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/amd/vulkan/bvh/ploc_internal.comp#L64 we decrease this here
16:19pixelcluster: we set it up in a way that the very first partition has a result already if I'm not completely mistaken
16:19cwabbott: https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/amd/vulkan/radix_sort/shaders/scatter.glsl?ref_type=heads#L1216
16:20pixelcluster: oh lmao, different decoupled lookback impl
16:20pixelcluster: never really looked at the radix sort shaders
16:20alyssa: this is what I mean ((((:
16:21pixelcluster: hmm that's kinda sad but I think if necessary we should be able to change it to do the decoupled lookback like the ploc shader without much issue?
16:22alyssa:wonders how this hasn't blown up on arm
16:23cwabbott: pixelcluster: how are you guaranteeing that all partitions are initialized though?
16:24cwabbott: iirc you're just pushing around the spinning to another spot
16:25pixelcluster: sort of yes, that's the part with the work-stealing queue thingy
16:26pixelcluster: having it be a work-stealing queue means the only forward progress guarantee we need is that workgroups that already started doing work won't get starved
16:27cwabbott: right, but that's the same guarantee you need for the original algorithm if you you assign indices with an atomic
16:27pixelcluster: right
16:28pixelcluster: yeah you don't get around some fwd progress requirements
18:33emersion: can i get an ack for this? https://lore.kernel.org/dri-devel/20240629152204.666748-1-contact@emersion.fr/
18:33emersion: still unsure what the R-b policy is for DRM…
18:36javierm: emersion: according https://drm.pages.freedesktop.org/maintainer-tools/committer-drm-misc.html#merge-criteria, I believe your patch already meets the merge criteria
18:36emersion: javierm: the patch is reviewed, but not by a kernel committer
18:37emersion: so i'm not sure what's the rule here, do i need at least an A-b from a kernel committer?
18:37javierm: emersion: but that document doesn't mention it as a requirement
18:37emersion: or a review from anybody is fine?
18:38javierm: you have a r-b and a t-b, so IMO it should be ready to be merged if you wish
18:38emersion: okay, that would certainly be very nice :)
18:39emersion: i suppose that the policy trusts committers for not pushing stuff with lazy/completely random R-bs
18:39sima: usual plea about testcase bugfix (if that doesn't exist), but otherwise land this
18:39sima: and yes
19:29soreau: zmike: thanks
19:34soreau: I have an issue when using radeonsi on amdgpu on RX580 with latest mesa, the compositor (wlroots) hits an assert in mesa and fails to start. This patch lets it run: https://termbin.com/f79o