08:09 MrCooper: karolherbst sima: according to https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3342#note_1877855 Nvidia GPUs actually can scan out from system memory
08:13 YuGiOhJCJ: do you know why glx.pc is not provided when I build mesa-23.0.3? it's a problem because when I build mesa-demo-9.0.0, glx is not found and so glxgears is not built
08:23 pq: YuGiOhJCJ, looks like it's provided by glvnd, like all GL related APIs.
08:28 YuGiOhJCJ: oops and I deleted libglvnd because I don't use it
08:29 YuGiOhJCJ: well, it means I need to keep libglvnd on my system
08:29 pq: emersion, zamundaaa[m], I guess we just need to start depending on the permanent connector ordering, wait for the kernel to break that, wait for users to complain, and then report a kernel regression. :-P
08:29 emersion: but afaik it's already somewhat broken in some situations?
08:30 pq: does it matter? all we need is something that used to work, and then doesn't.
08:31 emersion: "it worked once" is not what a regression means
08:31 pq: "it worked reliably for this user repeatedly, until they upgraded the kernel"
08:31 emersion: if a deferred probe makes it work 90% of the time, it's not a regression when it fails 10%
08:32 pq: that's not the failure case I'm thinking
08:32 emersion: ah, you're thinking driver changes order of its logic?
08:32 pq: I'm thinking no deferred probe involved, but driver code changes changed the order.
08:32 emersion: shuffles create_connector() calls?
08:32 emersion: right
08:32 cwabbott: anholt: there's one more fix required for ESO on turnip but it's still in review
08:32 emersion: yeah, that'd qualify
08:33 pq: emersion, but yeah, I agree, I'd prefer something that was intended as a persistent id.
08:36 MrCooper: YuGiOhJCJ: either that, or build Mesa with -Dglvnd=false
08:55 YuGiOhJCJ: MrCooper, if I build mesa with -Dglvnd=false, it won't help me because I want "glxgears" from "mesa-demos", so "glx.pc" is necessary and "libglvnd" has to be installed for that
08:56 sima: MrCooper, a surprise, but a welcome one
08:57 sima: emersion, pq I think gregkh is pretty stern on "driver load order resulting in different enumeration is not a regression" policy
08:58 emersion: sima, this isn't about driver load order
08:58 sima: ah I guess I misunderstood scrollback then
08:58 pq: sima, this is about connector registering order inside a driver.
08:58 emersion: sima, this is about eDP-1 being created before HDMI-1 in the driver
08:58 sima: how can that break userspace?
08:58 sima: you hardcode the connector_id instead of the name?
08:59 sima: s/hardcode/store in config/
08:59 emersion: if the driver decides to change its logic to create HDMI-1 before eDP-1, then it will break userspace using index as stable ID
08:59 emersion: connector_id is a KMS object ID no?
09:00 emersion: and connector_type_id is global, not per-driver
09:00 emersion: nor per-device
09:00 pq: sima, if we use the connector *index* in the connector array of get-reources as a stable identifier of a connector on a specific hardware device, then changing connector registering order would change that index and break our connector naming that is used in end user config files.
09:00 emersion: (note: we're aware this doesn't fly for DP-MST)
09:01 sima: yeah if userspace does that and a driver breaks I'll go grab the really good stuff and get wasted :-)
09:01 pq: sima, well, this is the only thing userspace could do atm.
09:02 sima: maybe celebrate the inglorious genius of making connector_type_id global too
09:02 pq: everything else is even worse
09:02 sima: pq, remap connector_type_id to be per-device?
09:02 pq: even if connector_type_id was per-device, it would still break if connector registering order changed, right?
09:02 sima: I think with all drivers it's safe to assume that that is stable
09:02 MrCooper: YuGiOhJCJ: AFAICT Mesa demos don't directly require glx.pc, so it should work if you re-generate its build system files against a non-glvnd Mesa build
09:03 sima: but e.g. the load order of edp vs hdmi might change, because those can be bridge drivers
09:03 emersion: we're talking about using the index, not the connector_type_id
09:03 sima: and with bridge drivers using component.c the driver load order impacts how they're called and registered
09:03 sima: emersion, yeah but I think the index is too risky
09:03 emersion: hm
09:03 emersion: so connector_type_id would be more reliable except for the fact it's global?
09:04 sima: remapping to counting 1st/2nd/3rd per connector type per device I think is something the kernel can sign up for as a full uapi promise
09:04 pq: per-device connector_type_id is better than array index which is better than current(?) connector_type_id
09:04 sima: yeah the current global connector_type_id is bonghits
09:04 sima: but instead of computing the index across all connectors, you could compute it across all connnectors of the same type
09:05 pq: true
09:05 sima: and I think that the kernel could sign up for as "yes it's stable uapi" and we document it as such
09:05 sima: kinda like we can (do?) sign up that crtc/plane are stable, since they're sometimes not equal
09:05 pq: maybe the kernel should provide a userspace library for stable naming of connectors :-P
09:05 pq: or like, libdrm
09:05 sima: but across types there's lots of drivers where it's stitched together from components and bridges and that's load order fun
09:06 sima: pq, yeah we can also do a little stable-id helper in libdrm that implements the promise I guess
09:06 MrCooper: YuGiOhJCJ: nvm, was looking at old demos snapshot
09:07 sima: emersion, pq probably should still check with drivers using lots of component/bridge to make sure they're confident we can make this promise, but my gut feel at least it it's a lot more doable than connector_id or connector index
09:07 MrCooper: YuGiOhJCJ: oh, but the toplevel meson.build has code to handle this
09:07 emersion: ideally we'd just have a connector prop but…
09:07 sima: oh could do that too
09:08 pq: sima, what about the full solution? a new KMS connector prop containing a hardware-dictated path?
09:08 sima: more-stable-name-totally-pinky-swear
09:08 emersion: ahahah
09:08 sima: pq, fine with me too
09:09 pq: like vsyrjala said: https://lore.kernel.org/all/20190613184335.7970-1-ville.syrjala@linux.intel.com/
09:09 sima: emersion, pq might be even better since for hotplugged connectors we could use then something entirely different like the path prop
09:09 emersion: yea
09:09 sima: and we could have the entire thing handled in drm core code I think
09:09 emersion: and this time not with a KMS object ID embedded in it…
09:09 sima: since we know which ones are hotplugged and which not
09:09 pq: that was already 4 years ago, damn
09:10 sima: pq, well lift it to drm code
09:10 sima: just autofill the path prop for !MST connectors in drm_dev_register or so
09:10 sima: and complain if any driver ever fails to set path prop for hotplugged connectors
09:11 pq: PATH prop is already broken, is it a good idea to use the same name?
09:11 sima: how is path prop broken?
09:12 pq: embeds a KMS connector id number
09:12 sima: oh lol
09:12 emersion: connector object ID
09:12 sima: yeah then it's something new we need
09:12 sima: the base connector id really shouldn't be in there
09:13 pq: one could say that userspace needs to drop that part and replace it with root connector's PATH, but that's... ugh.
09:13 sima: well it should be the base connector but with the per-device&type idx
09:13 emersion: yea
09:13 sima: pq, yeah it's useable, but it's not great without parsing and fixing things up
09:13 pq: it should be the base connector's TRUE_PATH, literally
09:14 sima: which you can do already in the way we just discussed, but I'm on board with the kernel doing the work to encode it per whatever uapi promise we come up with
09:14 sima: I do wonder whether we could change the sysfs name to this true path
09:14 sima: or too many scripts for that
09:15 sima: but I expect that since most systems have only one gpu we should be able to get away with that
09:15 sima: would be at least nice if we could put a more reasonable path name into sysfs, it's kinda meant to reflect the physical topology ...
09:16 pq: could the kernel do better with TRUE_PATH than just per-device per-connector-type counter? Like some actual hardware path resembling thing, e.g. go through bridges A-B-C then second connector on that.
09:17 pq: not that we'd need to tell userspace about bridges per se, but just as opaque tokens in the TRUE_PATH
09:19 sima: pq, I guess if we ever get the fun of different hdmi connectors going through different bridges we could use that topology internally to stabilize the numbers
09:20 sima: but feels like a bridge too far otherwise
09:20 pq: ok :-)
09:21 sima: I'm also not sure what userspace can do with that knowledge, unlike mst you're not going to resolder the chip-internal routing (or the pcb, but usually these are all on-chip)
09:21 pq: no, userspace would not *parse* that information.
09:21 emersion: i think the main upside would be that drivers would be less likely to break it
09:21 sima: yeah then I'd say it's better to not expose it, and only use internal once we need to
09:22 sima: because if we do, someone will get creative and parse it and create some fun with that perhaps
09:22 emersion: you could always sha1 the whole thing or something
09:22 emersion: but yea
09:22 sima: emersion, well we could iterate connectors by iterating encoders
09:22 sima: and then walking the bridge chain
09:23 sima: well don't even have to walk the bridge chain
09:23 sima: just check for which connector is there
09:23 sima: so that's pretty quick to implement I think, if we need it
09:24 sima: not sure we should do that from the start though, it'd be a bit brittle since there's a few funny corner cases
09:24 sima: (like multiple connector on the same encoder and things like that)
09:25 sima: and I'm not even sure it'd be good enough as-is, we might also need to make sure that encoders are then stable enough with their ordering
09:25 sima: so just pushed the problem around a bit
09:25 sima: and sha1 wont help since for encoder there's nothing more stable than their idx
09:26 sima: tldr; leaning towards "we solve this when it goes boom"
09:26 pq: yeah, which is why I was wondering if the identity string could be manuaactured from actual hardware arrangement.
09:26 pq: instead of counters
09:28 sima: we could sort by acpi/dt names maybe
09:28 sima: but that's a pile of typing
09:28 sima: and I'm not sure those are stable enough either
09:29 emersion: the failure case i'm worried about is when the kernel devs change the order of some function calls
09:29 emersion: and then don't realize it's a breaking uAPI change
09:30 sima: I think someone accidentally changing from fifo to lifo or the other way round with list walking to register/handle stuff is more likely
09:30 sima: the function call stuff is generally just calling into various connector/encoder types
09:31 sima: which is why I think per-type should cover all these
09:32 sima: but for the componentized drivers there's a lot of lists: struct device, component.c, bridge lists, the drm_device lists and probably more
09:32 sima: they all need to stay ordered the same or boom
09:56 tomeu: DavidHeidelberg: is it possible that docs/ci/kernel.rst is a bit out of date?
09:56 tomeu: I see it still refers KERNEL_URL and wonder if the rest matches the current state of things
10:17 tomeu: DavidHeidelberg: koike and btw, may be a good idea to follow these conventions to make it more obvious what each patch is coming from: https://chromium.googlesource.com/chromiumos/docs/+/refs/heads/stabilize-12441.B/kernel_faq.md#upstream_backport_fromlist_and-you
10:17 tomeu: but I see that there aren't that many patches, good job!
10:50 swick[m]: so, everyone agrees we need a TRUE_PATH prop but who's going to actually write it?
10:50 emersion: thanks for signing up!
10:51 swick[m]: didn't vsyrjala wrote some patches before? :P
16:16 DemiMarie: sima: In Qubes OS we want to be able to know which physical port a given device was plugged into. This is mostly the case for USB devices right now but knowing it for displays would also be very useful.
16:17 sima: I think for usb devices the plan is to sprinkle sysfs symlinks around so that you can figure that out
16:18 DemiMarie: The purpose of this is so that on certified hardware, we can display an image that shows where the device is plugged into the chassis. This is the only information about a device that a malicious device cannot spoof.
16:18 sima: but I haven't followed these plans closely, it's a bit a janky area
16:18 DemiMarie: sima: could the same information be provided for HDMI and DisplayPort devices?
16:19 emersion: something landed, but dmitry has objections
16:19 sima: DemiMarie, I have honestly no idea how/where we could even get that information from for most drivers/systems ...
16:20 sima: so I guess just hope everything becomes usb-c/dp/tb :-/
16:20 DemiMarie: sima: does the kernel have that information somewhere?
16:20 DemiMarie: Obviously the image generation is in userspace, I just need a number.
16:21 DemiMarie: Or is that hidden by some awful layer of firmware somewhere?
16:27 sima: DemiMarie, I don't even know whether it exists
16:27 sima: so definitely a use-case I see, but this is going to be some work to make it happen
16:28 gfxstrand: Ugh... I'm gonna need to do a big SPIR-V refactor... :cry:
16:29 gfxstrand: dschuermann: Does AMD hardware have caching/access flags for memory ops on the instruction?
16:30 gfxstrand: dschuermann: NVIDIA does and now I kinda want to put a nir_memory_semantics on load/store/atomic_global
16:30 gfxstrand: And then type a pass to add barriers as per what spirv_to_nir.c does today.
16:30 gfxstrand: cmarcelo: ^^
16:32 dj-death: gfxstrand: sounds possible on DG2+
16:32 dj-death: gfxstrand: but there are limitations with atomic_global
16:35 cmarcelo: gfxstrand: we expected someday we would use the semantics in loads and stores, why are you expecting a huge change though?
16:46 cwabbott: gfxstrand: yes it does
16:47 cwabbott: that was a regression when radv switch to the memory model intrinsics that never got fixed iirc
17:38 alyssa: gfxstrand: I believe AGX has cache flags on load/store/atomic but I haven't r/e'd any details yet
17:41 gfxstrand: cmarcelo: On older Intel, it's mostly just a barrier. On NVIDIA, there is potentially actual cache flushing involved. We could do that on a per-cache-line basis or we could do it across the device. Less is better.
17:43 gfxstrand: And it's easy enough to write a pass which replicates the current behavior of spirv_to_nir.c which drivers can drop if they want.
19:05 agd5f: DemiMarie, IIRC, there is the ACPI _PLD stuff, but I don't think I've actually seen that implemented properly anywhere. Also, it's tied to the platform so it wouldn't work for add in boards.
20:03 Lynne: have I mentioned how much I hate vulkan queries?
20:05 zmike: no
21:19 Lynne: I hate vulkan queries
21:19 zmike: how much
21:21 Lynne: maybe third, after... grr, user-synchronized queues and glsl... fourth! after glslang, user-synchronized queues and glsl
21:22 Lynne: you'd think that it just dumping everything in one big buffer is going to be a winning strategy, after all, it's what descriptor buffer does, which is beautiful
21:22 Sachiel: I guess you haven't worked with XFB