06:57 dj-death: mareko: hey there, do you think you could give a look at https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30038 ?
06:57 dj-death: mareko: looks good to me but I'm not really a huge expert on the mesa/state-tracker code :)
08:44 sima: mripard, I wonder whether we could even try to push the -next trees first, as a test, to catch people misplacing patches
08:44 mripard: it's weird still, because drm-misc-next-fixes was still at drm-misc-next-fixes-2024-06-07
08:44 sima: since the linux-next branch really should always be fast-forwards
08:44 sima: mripard, I haven't looked why it happened tbh
08:45 sima: maybe dim broke instead
08:45 mripard: so it hasn't moved in a month, and it was definitely working around that time
08:45 sima:kinda busy processing pr
08:48 sima: rodrigovivi, thellstrom, demarchi xe had a wrong rerere solution in drm-tip that resulted in https://paste.debian.net/hidden/df834b8a/
08:48 sima: spotted it while backmerging -rc6 into drm-next and fixed it there
08:50 thellstrom: Weird, I thought I fixed that yesterday?
08:50 thellstrom: sima: ^
08:52 sima: thellstrom, hm maybe git lost it again, sometimes it's confused like that
08:52 sima: thellstrom, https://drm.pages.freedesktop.org/maintainer-tools/drm-tip.html#removing-a-wrong-conflict-resolution did you use this guide to fix up drm-tip?
08:53 sima: or the section right after
08:54 thellstrom: Yup. I reverted Imres manual fixup which was after the merge of xe-for-CI and instead placed it after the merge of drm-next...
08:56 thellstrom: So the drm-rerere commit supposed to fix this is 3c92d77045fa9e736cb72bc88b9acdcf1cdc507d
09:02 sima: thellstrom, hm yeah I have that, maybe git just got confused because the context changed
09:02 sima: I had to redo a different xe conflict in drm-tip too after I merged the latest drm-xe-next from rodrigovivi
09:03 sima: git rerere isn't super smart, and sometimes even incompatible between different git versions
09:03 sima: but it's been a while I've seen one of those
09:06 thellstrom: Hm. Yes, I thought even weirder was how that line got added anyway. It's neither in the merge source nor destination and the result of of an automatic merge..
09:10 sima: thellstrom, we have rerere enabled, so you need to nuke the wrong stored conflict resolution
09:11 sima: deleting the fixup alone won't be enough if the issue is in the rerere side
09:11 sima: so the issue might predate imre's rerere commit, and imre just tried to patch it up with a fixup
09:11 sima: instead of deleting the root cause
09:11 sima: and you deleting the fixup means it pops back up
09:18 thellstrom: Well the fixup wasn't actually deleted but rather moved to where it surfaces. But IIRC I at some point added a conflict resolution to add such a line in an unrelated place so I may have to dig a bit deeper.
09:22 sima: thellstrom, well I deleted the fixup since it's baked in now
10:49 sima: robclark, bbd9d05618a6d608c72640b1d3d651a75913456a stumbled over this one and it's kinda ... ugh how that went in
10:49 sima: robclark, if cros/android really wants to push that I think we need to have some uapi docs for it to make it a proper stable tracepoint, like what pepp is doing
10:49 sima: and maybe more than one driver supporting it 4 years later :-/
10:51 lumag: mripard, do we need any other acks for https://lore.kernel.org/dri-devel/20240704-panel-sw43408-fix-v6-1-3ea1c94bbb9b@linaro.org/ ?
11:25 mripard: lumag: yeah, ideally someone maintaining amdgpu
11:26 mripard: I thought I acked that patch though?
11:35 sima: I think this is simple enough that one review/ack is enough
11:35 sima: once it's been 2-3 weeks on the list
11:36 sima: agd5f, found all your pulls, was blind
11:38 lumag: mripard, going through the ML history, no
11:38 lumag: you didn't
11:38 lumag: sima, ack.
12:08 daniels: spoiler: it’s literally llvmpipe https://youtu.be/LNva9WrwZ2A
12:14 cwabbott: wow, what a way to advertise... nothing
12:16 zmike: feels kinda bad to punch down on a channel with 8 subscribers
12:16 daniels: cwabbott: you just don’t understand their amazing innovation https://www.x-silicon.com/news/
12:35 imre: thellstrom, sima, ftr: the wrong merge result came about already before my 'dim push', see the earlier https://lore.kernel.org/all/20240628085457.21929-1-nirmoy.das@intel.com . After the push and noticing the build failure in drm-tip I also checked drm-rerere/rr-cache, but haven't found any resolution for the given line -> added the fixup (even though not after the correct merge point).
12:37 sima: imre, yeah it happens, rerere is sometimes a mess
13:02 robclark: sima: it isn't cros/android, it is perfetto
13:03 sima: robclark, well the original patch that landed the tracepoint in 2020 claimed it's for android
13:03 sima: msm is the first upstream driver using it
13:03 robclark: it is because android uses perfetto ;-)
13:04 robclark: anyways, it is a thing userspace tracing tools need.. and was already there.. so I used it ;-)
13:04 sima: yeah I just want to avoid a world where we have like android tracepoints (mostly downstream) and other tracepoints used by non-android
13:04 sima: kinda why I'm pestering pepp so much too
13:05 robclark: I didn't want to hack on perfetto to add a new thing.. so I used the existing thing
13:05 sima: robclark, yeah definitely don't want a 3rd thing just to make it even more messy
13:05 sima: but would be good to at least integrated that tracepoint into the same docs that pepp is working on
13:05 robclark: anyways, what is there seemed good enough.. anything else would just be more or less the same thing with a different coat of paint
13:05 sima: yup
13:05 robclark: fair
13:06 sima: I don't care about the pain brand, just that we're at least trying to document it and roll it out consistently
13:06 robclark: I hadn't been following the docs he is working on, but would make sense to have more than just the implicit "how perfetto uses it" docs
13:06 sima: kinda like the drm fdinfo situation, there's already much better consistency just by starting with some docs and forcing people to jointly bikeshed those
13:06 sima: robclark, yup
13:07 sima: also, some docs that we're trying really hard to keep those tracepoints stable across releases
13:07 sima: and consistent across drivers
13:07 sima: so that other traces can also use those
13:07 sima: *tracers
13:08 robclark: we don't have a choice but to keep that tracepoint as abi.. there is already userspace using it.. the time to bikeshed it has already passed
13:08 sima: eh, msm is the first one in upstream actually using it
13:09 sima: so you're the one baking it in
13:09 robclark: no, I mean perfetto is already using it
13:09 sima: yeah, but for the upstream no-regressions rule
13:09 sima: if we do a different one, we'll never break perfetto
13:10 sima: using the one perfetto uses means we must also pretty much keep it working as-is forever
13:10 robclark: right, but that is just creating more work for ourselves (ie. having to teach perfetto about a new thing)
13:10 sima: oh sure
13:11 robclark: I'm inherently lazy that way :-P
13:11 sima: bit of docs + some acks would still be good that nothing, because the og patch didn't even go to dri-devel iirc
13:11 sima: *better than nothing
13:11 sima:not much english today
13:12 sima: robclark, https://lore.kernel.org/dri-devel/?q=gpu%2Ftrace%3A+add+a+gpu+total+memory+usage+tracepoint <- this is a bit too little consensus finding for my taste :-P
13:12 sima: don't need much more, but should be a tad bit more than zero
13:13 sima: essentially drm uapi doc patch plus commit message that says "perfetto uses it, seems good enough" to dri-devel and I'll ack
13:14 sima: and maybe poke a few tracing people to make sure there's no violent disagreement
13:14 robclark: if you've got a pointer to what pepp is working on I'll take a look later and try to add something for gpu memory traces.. (it is holiday atm)
13:14 sima: it's stable uapi after all
13:14 sima: robclark, pepp is still very much wip, the uapi is kinda just a filler for now
13:15 sima: robclark, https://lore.kernel.org/dri-devel/20240614081657.408397-1-pierre-eric.pelloux-prayer@amd.com/ latest version I think
13:15 robclark: thx
13:16 sima: I think just a starting point is already much better, it really seemed to work pretty well to get drm-fdinfo into pretty good shape
13:16 sima: plus a lot of tursulin staying on top of things
13:16 sima: robclark, there's also stuff like maybe trying to make sure the ctx for the mem tracepoints has some relation to the ctx of the scheduler events
13:17 sima: that's probably the area where we're most likely to just make a mess for the dustbin
13:17 sima: and also whether userspace has any expectation of connecting that kernel ctx id with vk/gl context or not
13:18 sima: or with fdinfo stuff (but not sure we have those details there already)
13:18 robclark: sima: the tracepoint is global memory usage, fwiw
13:18 robclark: so no ctx
13:19 robclark: well, there is gpu_id
13:19 sima: yeah, but what do you put in there
13:19 robclark: but I guess that just maps to "create a different counter line"
13:20 sima: just want to avoid that one driver puts the drm minor in there, the next the hw engine and the third the logical ctx id
13:20 sima: fourth probably just goes with 0
13:21 sima: or that you can't align things with fdinfo output
13:21 robclark: minor is defn the wrong thing
13:21 sima: there's lots of ways to screw this up
13:21 robclark: maybe we should have a unique counter id for each drm device
13:21 sima: robclark, minor of the render node doesn't sound wrong to me for something that's gpu_id
13:22 sima: or the primary
13:22 sima: except accel messes that up ofc
13:22 robclark: each drm_device should have a unique id
13:22 sima: maybe?
13:23 sima: really my aim here is just to get people to ponder these details, and make sure the right folks are connected and we don't end up with fdinfo, sched tp and memory tp doing completely different things
13:23 sima: I fully expect that there will be at least some messy situations at first
14:21 Tashtari: Hi all. I upgraded mesa-24.0.7_1 to mesa-24.1.1_2 and Firefox started segfaulting when loading certain websites (Google Maps for one) and PDFs. Downgrading the package resolves the issue, and upgrading to the latest package (24.1.2_1) does not resolve it. I've collected a backtrace here: http://paste.debian.net/1322416/
14:22 Tashtari: Happy to collect any more data that might be needed to help resolve the issue. Can anyone take a look?
14:22 Tashtari: (I use Void Linux, btw)
14:31 pepp: Tashtari: which GPU are you using?
14:34 Tashtari: 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Cape Verde PRO / Venus LE / Tropo PRO-L [Radeon HD 8830M / R7 250 / R7 M465X] (rev 87)
14:47 pepp: Tashtari: looks like https://gitlab.freedesktop.org/mesa/mesa/-/issues/11352 - the fix isn't merged yet
14:50 Tashtari: Ahh, cool. Glad it's something already known.
14:50 Tashtari: Thanks for looking into it.
14:50 pepp: Tashtari: using the amdgpu kernel module instead of radeon is another possiblity to fix
14:50 Tashtari: It's cool, I can stay on the old version of mesa until the fix is rolled out.
14:51 pepp: sure
23:00 alyssa: does glcts have any coverage for indirect draws with tessellation? why would it have that? (-:
23:01 alyssa: ah, there's KHR-GL46.pipeline_statistics_query_tests_ARB.functional_tess_queries ... so you need full gl4.6 to get coverage for a gles3.2 feature, classic