08:03 tzimmermann: sima, hi. i made a patch series to better integrate gem-shmem with the kernel's page tracking (see https://lore.kernel.org/dri-devel/20260204114341.195143-1-tzimmermann@suse.de/T/#m29bf6ed03bdbb0a177ad5c37b89f61c672200b73). but now I've come accross the old commit 8b93d1d7dbd5 ("drm/shmem-helper: Switch to vmf_insert_pfn"). Although get_user_pages doesn't seem to be relevant any longer, I assume that mmaping with
08:03 tzimmermann: VM_PFNMAP is still a deliberate choice?
08:04 tzimmermann: bbrezillon ^
08:14 MoeIcenowy: tzimmermann: BTW do you have any free time for applying my DC8200 v7 patchset?
08:14 MoeIcenowy: sorry for disturb
08:14 MoeIcenowy: (or maybe my SMTP server failed?
08:15 tzimmermann: MoeIcenowy, hi. sure. i'll take a look later today. everything goes into drm-misc, right?
08:15 MoeIcenowy: I think it's patch 1-5
08:15 MoeIcenowy: 6-7 is already in thead tree
08:15 tzimmermann: ok, 1 to 5
08:16 tzimmermann: don't worry about reaching out via irc. email get lost too easily in my busy inbox
08:16 MoeIcenowy: hahaha
08:17 MoeIcenowy: managing such a big tree sounds busy
08:17 MoeIcenowy: ah should I send a follow up patch add T: drm/misc for the driver?
08:17 MoeIcenowy: I think many other SoC KMS drivers has it
08:19 bbrezillon: tzimmermann: unfortunately, I don't know enough about MM to help here :grimacing:. I did find this idea of flagging individual folios dirty/accessed when the are faulted appealing though. I guess this can still be done with PFN mappings, because we have the pages array at the gem_shmem level
08:21 tzimmermann: bbrezillon, yeah, we can still track access and dirty for the entire buffer with the existing pages_mark_ flags
08:22 bbrezillon: nah, I mean even fine-grained tracking is possible, I think
08:22 bbrezillon: you can just use the vmf->pgoff to get the right page, and turn into a folio
08:23 bbrezillon: *the right page in the gem_shmem::pages[] array
08:23 tzimmermann: MoeIcenowy, sure that follow-up makes sense
08:23 tzimmermann: bbrezillon, right. then let's try that
08:24 bbrezillon: first commit in the patchset is good to go, if you want to apply it now
08:31 MrCooper: (how) can a compositor detect that a connected monitor is powered off?
08:35 K900: Depends on the monitor really
08:35 K900: Some will report it over DDC/CI but also DDC/CI is probably not something you want to be touching by default
08:50 MoeIcenowy: Some monitor just de-assert HPD on poweroff
08:50 MoeIcenowy: although this kind of monitor tends to create more problems
08:51 MrCooper: yeah, my question was specifically about monitors which don't do that
08:51 K900: Yeah I think it's between DDC/CI shenanigans and nothing
08:51 K900: At least for the overwhelming majority of cases
08:51 K900: And DDC/CI is giga cursed
08:54 MrCooper: 'ddcutil vcpinfo --verbose' doesn't have anything obviously related for this monitor (looks like one could turn off the monitor via DDC/CI though :)
09:36 mlankhorst: remote: ERROR: The git server, Gitaly, is not available at this time. Please contact your administrator.
09:36 mlankhorst: Works on 5th attempt
09:43 MrCooper: that was probably due to gitlab getting upgraded, as discussed on #freedesktop
11:58 sima: tzimmermann, yeah, very much
11:58 sima: or at least VM_SPECIAL, to make sure get_user_pages does not work
12:00 sima: I've even done patches to ensure every gem and dma-buf mmap is VM_SPECIAL, but there's some exceptions on some embedded platforms where dma_mmap gives you a gup-able mapping unfortunately
12:00 sima: so can't enforce that in full generality, but maybe we should try at least for x86 to make sure this doesn't ever break
12:00 sima: x86 and arm64 maybe, should cover most things
12:01 sima: but also auditing this is an absolute pain, there's so many paths
12:19 tzimmermann: sima, i see
12:23 tzimmermann: as discussed, i think we can keep the mapping as it is and track the pages internally
14:35 zmike: anholt_: how does --env work with deqp-runner for setting multiple variables? is it supposed to be like `--env VAR1=val VAR2=val` or `--env VAR1=val --env VAR2=val` or ?
16:44 anholt_: zmike: probably both work? just try it.
16:47 zmike: yolo
17:00 dcbaker: robclark, zdobersek: This was the commit https://gitlab.freedesktop.org/mesa/mesa/-/commit/5da94d1c6ec4734ff020207e09c1ad42469d6da9
17:01 robclark: dcbaker: right, but do you have a link to the ci job with UnexpectedPass's?
17:02 dcbaker: robclark: it's split across both shards: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/92145142 and https://gitlab.freedesktop.org/mesa/mesa/-/jobs/92144528
17:02 robclark: thx
17:07 robclark: dcbaker: looks like those were removed from xfails in 4cfa188db62dadca3342f3d6b02379b190745733
17:08 dcbaker: robclark: thx, I was looking in the completely wrong set of CI files for that set of errors
17:08 robclark:did too at first
17:09 dcbaker: Interestingly, I don't have that patch or the one it fixes in the 25.3 tree
17:10 dcbaker: So now I'm even more confused, because I have non of the work that Faith did for nir_lower_sysvals_to_varyings()
17:10 robclark: it could have been those were fixed earlier but not run in pre-merge CI? Maybe cwabbott remembers
17:11 robclark: I'm guessing that for some reason the 26.0 branch is running a different set of tests in a fractional run?
17:13 dcbaker: quite possibly? I'm pretty sure that I've seen at least a deqp/khronos-cts bump in 26.0 that isn't in 25.3
17:13 dcbaker: We're down to the last couple of releases where things have diverged enough that we end up with these weird situations, lol
18:06 anholt_: daniels: getting back to previous question: failures.txt is "differences-from-expected.txt", but doesn't include flakes (since it's not a "update your baseline" thing). I was suggesting that we might include flakes, though that breaks the initial-setup `mv failures.txt board-fails.txt` workflow. so either a new file with just flakes, or a new file with both failures and flakes, and I don't care much either way.
18:08 daniels: anholt_: oh, iswym. yeah, your original plan sounds good to me.
19:17 dcbaker: robclark: those tests are the only thing left for me to cut a release today, unless you have a problem with it I'm just going to mark them as expected pass and cut the release
20:11 zdobersek: dcbaker: I'm off the hook, right?
20:12 dcbaker: zdobersek: Yeah, I'm going to just mark them as expected passes and make the release
20:34 robclark: zdobersek: yeah.. in the end drop them from xfails
22:49 tarceri: mareko: thoughts on whats going wrong with ac_nir_opt_outputs here? https://gitlab.freedesktop.org/mesa/mesa/-/issues/14443
23:46 memleak: hello, is the d3d12 driver in mesa made to be used the same way as the old and removed galliumnine driver or how does it work?
23:48 anholt_: memleak: no, it's a gl driver that calls to d3d12.
23:48 memleak: the mesa3d page says it's to support opengl cards on d3d12 only cards, but two things.. don't all d3d12 cards support opengl? and secondly; does it only translate opengl -> d3d12 or vice versa as well?
23:49 anholt_: if you want something that implements d3d, dxvk and vkd3d are the projects to look at.
23:50 memleak: yeah i was just hoping that this was the modern reincarnation of galliumnine because it worked so well but the d3d12 variant.
23:51 memleak: dxvk is buggier and less accurate than wined3d in my experience. lots of sims 4 crashes.
23:51 memleak: whelp, thanks anholt_!
23:51 memleak: are you still at intel?
23:52 memleak: you did an absolute shit ton of work on i915/i965 IIRC
23:52 anholt_: not for over a decade, no.
23:53 memleak: oh, can i ask where you've moved to?
23:54 anholt_: Igalia
23:55 memleak: i'm on an i5 1135g7 right now (temporarily) using the new Xe driver on it, been working nicely. don't have a desktop atm
23:57 memleak: had a few kernel panics though without the power management stuff on in the kernel