07:58jfalempe: tzimmermann: regarding ast-i915 dma-buf sharing, there is a missing cache flush somewhere in i915, and Intel is looking into this, as I don't have the hardware knowledge to fix it properly.
07:59tzimmermann: jfalempe, ah ok. i see
07:59tzimmermann: surprising to me that no one spotted this bug before
08:13MrCooper: it's also unclear why a CPU cache flush would be needed, since the importer uses the CPU for accessing the buffer storage
08:19jfalempe: MrCooper: those integrated GPU are tightely coupled with the CPU, sharing some cache, so that can explain it.
09:20pq: silurian_invader, maybe it's not actually that unlikely for userspace to attempt a configuration the hardware can do.
09:20pq: without any new code in userspace, that is
12:04anonymix007[m]: Venemo: so I got vk cts to compile, however, it seems to execute zero out of zero tests which is obviously useless
12:04Venemo: anonymix007[m]: how are you trying to run it?
12:04anonymix007[m]: $ ./deqp-vk.exe --deqp-caselist=vk-default.txt... (full message at <https://matrix.org/oftc/media/v1/media/download/AcHXZcHjsmpEmXp_gEKE97T7oJ6hQtjpZ4n4HF0RzCmhDRKEP659740Ry0lTKNA6ttc_4VSgDXmQKGaQRx0XBYpCeauua6ggAG1hdHJpeC5vcmcvS2JVdW15blpQeUx1bVRYd0JiV2FKdXNr>)
12:05anonymix007[m]: Venemo: so basically exactly as readme suggested
12:07Venemo: what is it saying?
12:08Venemo: something doesn't look right. you are running deqp-vk but then in the output it says it is running the opengl cts
12:30anonymix007[m]: Venemo: the above is the full output of that executable.... (full message at <https://matrix.org/oftc/media/v1/media/download/AfBxUcivgs1sAtHVTXK0MyFzyGnXEzPxtjBc00Me93cSod-w7HiVD5DgIo9fCuxdlHGpqeN4vTzzwTIIBfRXiKtCeauv6d9wAG1hdHJpeC5vcmcvelVIenVXU3d3T1hVS09IUlFqYnFxdlNX>)
12:31Venemo: I don't see what is going wrong with it at the moment
12:31Venemo: my recommendation would be to try to make it work in a "normal" environment first, then try mingw
13:06pendingchaos: anonymix007[m]: use --deqp-caselist-file instead of --deqp-caselist
13:07pendingchaos: the "opengl-cts-4.6.7.0-141..." probably doesn't mean anything, I get "vulkan-cts-1.4.3.2-299..." when I run glcts
13:18alyssa: pendingchaos: that's the branch you built from
13:18alyssa: vulkan-cts branches aren't technically valid for GL CTS submissions
13:23karolherbst: couldn't you do a "I base of opengl-cts-... with those upstream patches on top: ..." for GL submissions?
13:28alyssa: yes
13:45karolherbst: I wonder how people here are feeling about mesa using -static-libstdc++ ?
13:46karolherbst: I'm considering because: https://gitlab.freedesktop.org/mesa/mesa/-/issues/14090#note_3182691
13:47alyssa: gg
13:47karolherbst: I suspect it would also mitigate the libstdc++ issues mesa runs into with games
13:47K900: As a distro that has to deal with ABI mismatches between Mesa and random things users install, I would love to one day just have Mesa compiled as a single static library tbh
13:47K900: With all the symbols namespaced
13:48K900: But I know that's going to be an immense pain to make work
13:48karolherbst: well mesa would remain shared, because that's how it needs to be
13:48karolherbst: this is just to link libstdc++ statically
13:48K900: I mean as a more general case of this
13:48karolherbst: like
13:48K900: (though it would still have to be shared, technically)
13:48karolherbst: yeah but GL, vulkan and OpenCL all require shared libraaries
13:48karolherbst: though if you mean to link all dependencies statically?
13:48karolherbst: well
13:48K900: Well yes, not actually static, just no external symbol dependencies
13:48karolherbst: distros could already do that
13:49karolherbst: right...
13:49K900: I don't think you can
13:49K900: At least not in a way that's at all sane
13:49karolherbst: yeah.. I mean you'll leave some C libs be shared like dl and stuff
13:49karolherbst: that's fine
13:50karolherbst: but yeah, maybe I should open an MR about this and do it for rusticl first and if others want GL/Vulkan to link statically it should be easy to do
13:50karolherbst: *link libstdc++ statically
15:04anonymix007[m]: pendingchaos: thanks! This seems to go a bit further, now deqp-vk just segfaults here: https://github.com/KhronosGroup/VK-GL-CTS/blob/main/external/vulkancts/modules/vulkan/protected_memory/vktProtectedMemAttachmentLoadTests.cpp#L323
15:24silurian_invader: pq: how do you mean?
15:25pq: silurian_invader, userspace (well, Wayland compositors) have some algorithms to try to build up a good KMS planes arrangement for their scenegraph.
15:26pq: It tends to involve iteratively building an atomic commit and testing it while adding or removing pieces, like planes used.
15:26silurian_invader: when I tested weston, it only used the primary plane, and it did not use the overlay plane
15:26silurian_invader: is there a way to debug that?
15:26pq: yeah, a moment...
15:29pq: silurian_invader, if you run 'weston -l log,drm-backend', your should get a massive flood of debug prints about how it interacts with KMS and why surfaces are not going to KMS planes.
15:30silurian_invader: thanks, I'll try that
16:06alyssa: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38313 needs review from NIR backend maintainers
16:07alyssa: hopefully you like it. I do
16:26silurian_invader: ah looks like the "overlay" (underlay) is not being used because "primary's zpos value (1) higher than plane's maximum value (0)"
16:26silurian_invader: which makes sense
16:27silurian_invader: is changing the primary plane an abi break?
16:28silurian_invader: I'm wondering if we could swap the default primary so the plane with alpha enabled by default is the overlay
17:36pac85: So I have a question regarding this bit of code https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/mesa/state_tracker/st_program.c?ref_type=heads#L842
17:36pac85: So, if all the clip planes are disabled none of the lowering runs. Makes sense, but as part of the lowering this pass runs https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/mesa/state_tracker/st_program.c?ref_type=heads#L702
17:36pac85: Which will replace and write to ClipDistance with 0 to disable that plane. Now the combined effect here is that if all planes are disabled then the clipdistance variable is not touched but if any plane is enabled then the remaining disabled ones will be overriden with 0. I'm guessing the point is to make sure that user clip planes and clip distance don't get used at the same time for different planes? (ie. that if at least one ucp is
17:36pac85: enabled clip distance written from the shader is ignored?)
17:56Ermine: what is the current state of vmgfx driver? is it in desperate need for love, or is it alright?
18:08Venemo: MrCooper: hey, I noticed your comment on drm/amd issue 662, I wonder is this purely a compositor issue or is there something I could do to improve the behaviour of DC here?
18:11agd5f: Venemo, IIRC, Ivan was working on hpd filtering patches, but they caused other regressions and he was working on resolving those
18:11Venemo: what exactly is the issue here? I don't see what it has to do with HPD, considering there is no plug/unplug happening
18:12Venemo: also don't see why the non-DC code would be unaffected, considering it uses the same HPD interrupt
18:12MrCooper: the issue is spurious hotplug events getting generated when the monitor scans its inputs
18:12agd5f: IIRC, some monitors do input polling when the signal from the GPU goes away. The input polling causes hpd interrupts
18:13MrCooper: IIRC programming different thresholds for "long" vs "short" HPD pulses, or something like that
18:13Venemo: why would the same not happen on the non-DC code path?
18:13MrCooper: ^
18:13Venemo: aha
18:20Venemo: interesting
18:20Venemo: so DC registers it as unplug then replug?
18:22agd5f: well as an unplug and so they send the hpd event to userspace and the compositor then checks for new displays, sees a display attached and then lights it up
18:23Venemo: I see
18:23Venemo: but shouldn't DC recognize that this is in fact the same monitor?
18:24Venemo: I'm pretty sure it has some code for that somewhere
18:27agd5f: I don't know that we get another HPD event
18:29daniels: see also https://lore.kernel.org/dri-devel/20251111162338.15141-1-marius.vlad@collabora.com/ for fixing a race condition within the KMS uAPI
18:31daniels: namely that if we get a hot-unplug followed by a hotplug in rapid succession, the kernel can send HOTPLUG=1 without a connector ID, so when userspace polls the connector list it sees a connector it previously knew to be connected as ... still connected ... so does nothing to re-establish the link
18:32Venemo: do I understand this correctly? so basically DC gets a hotplug event for something that is already plugged in? and fails to realize it's the same display and notifies userspace?
18:32Venemo: or is there also an unplug event?
18:33agd5f: IIRC, there just a single hotplug event in udev. Userspace would then decide whether it's plug or unplug based on what changed
18:34vsyrjala: the "bad link" status should be set whenever the link has dropped, or the kernel driver should retraing/etc. automagically
18:34agd5f: in this case, it's DPMS off
18:34agd5f: so the link is already down
18:34daniels: right, but if you have disconnected -> kernel sends HOTPLUG=1 -> connected -> kernel sends HOTPLUG=1 -> userspace wakes up -> userspace checks connector status -> userspace sees still connected, then userspace won't know what's changed unless we have LINK_STATUS=bad, which isn't sent in all cases?
18:35Venemo: agd5f: right, but I mean does DC see it as unplug+replug?
18:35Venemo: I suppose in this case DC should be smarter and swallow the event, since nothing actually happened
18:37agd5f: well, I think there is just an HPD interrupt. Same interrupt for plug or unplug. Should be able to check on the status of the pin though
18:37Venemo: yes, that's what I mean
18:37vsyrjala: not sure what the issue is with hotplug during dpms off. the link is down, so it will get trained when going back to dpms on
18:38agd5f: and that is what happens
18:38agd5f: but the user wants the monitor to stay in dpms off
18:38agd5f: it's a spurious hotplug
18:38vsyrjala: oh, that problem. yeah we have tons of display in ci which do that crap
18:39Venemo: I haven't actually seen the problem in person, just was curious if there is something i can do about it
18:40Venemo: I am working on the opposite problem (display not waking up when it should), looks like it's a completely different problem
18:42vsyrjala: i'm thinking userspace should perhaps remmber what was connected recently, and if it was in dpms off previously then go back to dpms off when same monitor re-appears (unless enough time elapsed that it might be a real hotplug)
18:45Venemo: vsyrjala: would it not be equally reasonable for the kernel to do the same?
18:47vsyrjala: that would require not notifying userspace about the unplug at all, and wait a while to see if the replug happens
18:47Venemo: MrCooper is it an option to change the programming for those HPD pulses in DC to the same values as non-DC? or is there a use case that would be broken from doing so?
18:48Venemo: vsyrjala: yes, that's what I had in mind
18:49zamundaaa[m]: Do keep in mind that this will also result in userspace doing atomic commits on a disconnected connector
18:49Venemo: userspace shouldn't so any commits while the monitor is turned off, should it?
18:50vsyrjala: in i915 we can't really defer the unplug, because of silly reason like crappy typec firmware/etc. things need to be turned off fairly quickly on disconnect
18:50zamundaaa[m]: If you do it specifically only while it's supposed to be off anyways, that sounds like a good solution
18:52Venemo: zamundaaa[m]: that's what this is about basically. the display turns off (as it should), then goes crazy. but it should be off the whole time
18:52Venemo: vsyrjala: you mentioned you have some monitors that do this in the CI. does that imply you have a good solution in i915?
18:53zamundaaa[m]: I'm familiar with the problem. When we broke the workaround in KWin for it recently, we got quite the flood of bug reports...
18:56vsyrjala: iirc we have some hacks in ci to retry when spurious hpds interrupt some timings sensitive test
18:57vsyrjala: i don't remeber if we also put in something to fitler out spurious hpds
18:59Venemo: zamundaaa[m]: looks like it's still broken, based on reports from users in that thread
19:03Venemo: vsyrjala: I see. so it's an unsolved problem outside of CI?
19:04vsyrjala: yeah. my take is that it needs to solved in userspace
19:07Venemo: hm.
19:07Venemo: maybe a silly question but why was this not an issue under X? or was it?
19:08zamundaaa[m]: It was an issue under X
19:08zamundaaa[m]: Still is
19:08zamundaaa[m]: Just not a whole lot of users there anymore
19:09Venemo: aha
19:09Venemo: zamundaaa[m]: do you happen to have a link to the relevant kwin bug?
19:10Venemo: if we agree that this should be handled in userspace, then I'll just link to that issue and close the drm/amd bug
19:12zamundaaa[m]: https://bugs.kde.org/show_bug.cgi?id=480026 is one of the bug reports for it
19:12zamundaaa[m]: It's worth mentioning that the workaround doesn't seem to smooth over all issues
19:13zamundaaa[m]: I suspect there may be some driver issues, or just broken displays involved
19:13zamundaaa[m]: IIRC one of the bug reports about the workaround not being good enough had like 20s between hotunplug event and hotplug event
19:14Venemo: damn
19:15Venemo: what do you think the driver could do to improve the situation?
19:16vsyrjala: this reminds that i need to debug my own display setup at some point. i have a kvm switch and if i switch between certain machines when displaying all black, the display stays black after the switch
19:17vsyrjala: dunno if it's the machines, the kvm switch, or the monitor at fault
19:17Venemo: vsyrjala: that sounds similar to the "doesn't wake up" issue
19:18zamundaaa[m]: Venemo: I'm not sure, finding out probably requires debugging the specific most problematic setups
19:19zamundaaa[m]: Afaik the same sort of issues happen on Windows too, probably some cases are really just the display being stupid
19:19zamundaaa[m]: One option userspace could go for is to offer a toggle that just disables hotplugs waking screens entirely
19:19zamundaaa[m]: We have an env var that basically ends up being that way
19:20Venemo: wouldn't that negatively affect normal hotplugs as well?
19:20zamundaaa[m]: Yep
19:21zamundaaa[m]: We could even make it a per-display setting though, so users with problematic displays can just patch it up themselves
19:22zamundaaa[m]: The negative side effect isn't that bad imo, you just have to use the keyboard or mouse to wake the screen after dpms off. I imagine the situation where you do dpms off and then intentionally plug in a new screen and expect it to wake immediately are rare
19:23Venemo: yeah that sounds reasonable
19:23Venemo: I mean it's a reasonable default even. when all current displays are dpms'ed, then it makes sense for a newly plugged in one to be dpms'ed as well
19:25Venemo: I wonder how other operating systems deal with this though
19:46anonymix007[m]: So I got around that segfault in the CTS and while many tests are already passing, I see the dEQP-VK.api.info.image_format_properties2.1d.optimal.undefined test crashing here: https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/virtio/vulkan/vn_common.c?ref_type=heads#L268
19:46anonymix007[m]: Any suggestions on what should I look for?
22:57airlied: glehmann, gfxstrand: since gfxstrand seems to want to stay out of it, what do you think about alyssa idea of introducing a new instr type for cmat call?
22:57airlied: I'd like to get back to making some fwd progress on these patches
23:30pac85: So like, how does this not break xfb when you stream out glClipVertex? https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/compiler/nir/nir_lower_clip.c?ref_type=heads#L192
23:54alyssa: pac85: who told you it doesn't :p
23:56pac85: alyssa: right lol, wonder who would mind if I deleted that line. Zink sure wouldn't :p