00:40 gfxstrand: karolherbst: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24764
00:45 karolherbst: seems to work :)
00:48 gfxstrand: First try, even?
00:48 karolherbst: yeah
00:48 gfxstrand: \o/
00:48 karolherbst: didn't theck the shader though
00:49 gfxstrand: Let's throw it at some CI to see if it blows rusticl up
00:49 karolherbst: I have a collection of other random patches I'll have to upstream anyway and tomorrow is time off, so I might do some of that stuff next week
00:49 karolherbst: I also need SpvCapabilityFPFastMathModeINTEL for random stuff, but I think we can just enable that one...
00:52 karolherbst: getting a lot of "iris: Failed to submit batchbuffer: No space left on device" in random tests... sadly nothing tells me what the problem is, though I think my SVM impl is borked
00:53 alyssa: gfxstrand: have you considered using nir_shader_intrinsics_pass
00:53 alyssa: :~P
00:53 karolherbst: there is a memcpy3D tests :')
00:53 karolherbst: memcpy3D: ../src/compiler/nir/nir.h:1655: nir_deref_mode_is_in_set: Assertion `nir_deref_mode_must_be(deref, modes)' failed. ah yes... that issue
00:54 karolherbst: that's even _with_ the MR fixing some of it
00:54 karolherbst: but there is more annoying stuff going on
00:54 karolherbst: generic pointer nonsense
00:56 karolherbst: CapabilityInt64Atomics oh boi...
00:58 karolherbst: anyway.. I think I'm happy enough with my current global program varaible implementation, I just have no idea how to deal with those "constant" pointers to variables nonsense :'(
00:59 karolherbst: or rather, I have ideas, I just hate them all
01:20 karolherbst: gfxstrand: I found a couple of tests where I ran into explicit stride asserts after memcpy lowering
01:20 karolherbst: will investigate later
01:21 karolherbst: probably just me having a weird order of passes
01:21 karolherbst: ehh..
01:21 karolherbst: it's after opt_memcpy
01:21 karolherbst: nvm
02:01 gfxstrand: karolherbst: Pushed with some improvements.
02:04 gfxstrand: Pushed again. One of the fixups was bogus
02:04 gfxstrand: karolherbst: It should now be patching alignments through properly
02:24 DemiMarie: Are there plans to fix the blocking in vkQueuePresentKHR?
02:25 gfxstrand: What do you mean?
02:26 DemiMarie: https://dudemanguy.github.io/blog/posts/2022-06-10-wayland-xorg/wayland-xorg.html complains that vkQueuePresentKHR() blocks if the Wayland compositor is throttling drawing, in violation of the Vulkan spec. Is this accurate, and if so, are there plans to fix it?
02:28 gfxstrand: Uh... I don't think we're violating anything
02:29 gfxstrand: And I don't think we block.
02:29 gfxstrand: Yeah, we have a throttle thing.
02:29 gfxstrand: We have a throttle thing for X11, too.
02:29 gfxstrand: We have them because apps are dumb
02:32 gfxstrand: There's not much I can do with an unhinged rant. If someone wants to file a bug with an example of said misbehavior and can explain what they think Vulkan requires there, we can talk about it. A giant rantpost about how everything is terrible that just assumes the reader agrees isn't actionable.
02:32 DemiMarie: https://github.com/glfw/glfw/issues/1350 or has something changed since then?
02:32 ids1024[m]: If it waits on wl_surface_frame callbacks, it may block indefinitely for occluded windows.
02:32 DemiMarie: gfxstrand: yeah, good point, that is my fault for linking the blog post.
02:33 DemiMarie: sorry about that
02:34 gfxstrand: If the app requests FIFO, yes, we're going to block on frame callbacks. That's literally what they asked us to do.
02:34 DemiMarie: ah okay
02:34 gfxstrand: If you don't want us blocking on frame callbacks, requrest MAILBOX.
02:34 gfxstrand: *request
02:34 DemiMarie: so this is just buggy apps that don’t realize that they need to have an event driven main loop?
02:34 gfxstrand: Or that use FIFO instead of MAILBOX
02:35 gfxstrand: With Wayland, you really should be using MAILBOX and handling the frame callback yourself or in the toolkit.
02:35 DemiMarie: Makes sense
02:35 gfxstrand: And, yes, there's a bit of a mismatch between the way FIFO and SwapInterval are specified and Wayland app throttling.
02:35 DemiMarie: Is using MAILBOX the appropriate thing on other platforms too?
02:36 gfxstrand: Well, you want some amount of throttling everywhere.
02:36 gfxstrand: If you use FIFO, you get throttling.
02:36 gfxstrand: That's what it's for.
02:36 gfxstrand: With Wayland, you can actaully manage it yourself and get something more predictable.
02:36 DemiMarie: makes sense!
02:36 gfxstrand: With X11, the best you can do really is FIFO/eglSwapInterval(1)
02:37 gfxstrand: If you set MAILBOX, there is a 1:1 mapping between vkQueuePresent() and wl_surface.attach/commit.
02:37 gfxstrand: The Vulkan spec even says so. :-)
02:37 DemiMarie: sorry for wasting your time
02:43 gfxstrand: No worries.
02:43 gfxstrand: Oh, I think I know why we do extra blocking in Vulkan for Wayland
02:45 gfxstrand: I guess we do block for everything other than MAILBOX
02:45 gfxstrand: But, also, you should always use MAILBOX with Wayland.
02:46 gfxstrand: Well, we don't block much
02:47 gfxstrand: That's probably more of a documentaiton problem than anything
08:55 MrCooper: gfxstrand: it would be possible in principle to do FIFO without blocking in vkQueuePresentKHR, it would require new Wayland protocol though
09:00 emersion: explicit-sync-v1 can do it
09:00 emersion: er, v2
09:18 MrCooper: that can't do FIFO semantics
09:19 emersion: i believe it can
09:20 emersion: send an unmaterialized sync point to the compositor, signal the sync point on presentation-time feedback of the previous frame
09:24 MrCooper: or on the frame event, I see, clever :)
09:31 karolherbst: gfxstrand: new code seems to cause a "Floating point exception (core dumped)"
09:32 karolherbst: but that's probably my fault :)
09:32 karolherbst: no allignment information is there
09:34 karolherbst: I'll post more infos on the MR
09:38 MrCooper: emersion: would that require multiple acquire points (another one for the Vulkan acquire point) for the same buffer attachment in the protocol?
09:39 emersion: MrCooper: it should be possible to have a presentation timeline, which chains the Vulkan API acquire point and then the FIFO point
09:39 emersion: such that the point submitted to the compositor depends on both
09:42 MrCooper: what if the sync points immediately before and after the Vulkan acquire point are already used?
09:43 emersion: the presentation timeline is completely independant from the Vulkan API's
09:43 emersion: Vulkan user submits frame with timeline A and point 42
09:43 MrCooper: k, good
09:44 emersion: mesa transfers this point to timeline B, point 1
09:44 emersion: then adds a new point 2 to this timeline for FIFO purposes
09:44 emersion: and sends timeline B, point 2 to the compositor
09:45 MrCooper: the same principle could be used for "not before" presentation timing as well
09:46 emersion: yeah
09:46 emersion: the obvious downside is that since the latching is client-side, there may be races
09:46 emersion: but on the other hand it's as flexible as it gets
09:47 MrCooper: and the compositor/kernel might be able to do a better job if they know the target ahead of time
09:47 emersion: can always start with client side and offload some of it to the compositor in the future once we have more exts
09:47 emersion: right
09:48 MrCooper: agreed, good approach in general
09:49 MrCooper: a Mesa implementation of FIFO using the v2 protocol seems like a good thing to use as one of the 3 implementations required by the protocol process
09:50 emersion: my original plan was to implement the upcoming ext to present with timelines
09:51 emersion: but yeah, that'd be a good alternative as well
09:51 MrCooper: yeah, either or both seems nice
09:54 MrCooper: swick[m]: ^ might be interesting to you
10:15 swick[m]: interesting idea
10:17 swick[m]: but presentation-time feedback is still not the thing you should be using for FIFO semantics
10:20 MrCooper: agreed, frame events are better for that
10:34 karolherbst: gfxstrand: but anyway.. it seems like copy_deref lowering also needs a similiar fix to that memcpy lowering as it can also explode in size with huge arrays
10:50 emersion: pq: you might be interested in this thread https://lore.kernel.org/dri-devel/6097eb1d-6b00-4a0f-a91f-5b19f2b422eb@linaro.org/
10:54 pq: USB subconnector type...
10:57 pq: maybe USB-C becomes a new top-level connector type, and then it has sub-types HDMI (dongle), DP (dongle), DP-alt (USB-C alternate mode or what is it?), etc.?
10:59 pq: or should dongles be more MST like nowadays?
11:00 pq: i.e. dynamically create MST connectors - but that might be confusing
11:01 emersion: pq, will break existing user-space
11:01 pq: which suggestion, how?
11:02 emersion: existing DP connectors, which are physically USB-C, can't have their type changed
11:02 pq: d'oh
11:02 emersion: breaks compositor config files etc
11:04 emersion: we could have a cap or something, but not sure it's worth it
11:04 emersion: we'd probably want a prop anyways…
11:04 emersion: to be able to expose the exact USB-C connector device
11:05 pq: connector props to supercede all the current "connector type" fluff?
11:05 emersion: e.g. a "usb_device" prop with "5-2:1.1"
11:06 pq: sounds good at first hand
11:06 emersion: we could have a "type" property which supersedes the type field, yeah
11:06 emersion: but we need to clearly define it
11:06 emersion: (and that wouldn't link to the USB device)
11:07 pq: it might link... depending on how it's defined
11:07 emersion: i'd expect a KMS enum
11:08 emersion: if it's a string, "type" is probably not a very good name
11:08 emersion: reminds me of the "PATH" stuff…
11:09 emersion: "PATH" = "usb:5-2:1.1" is tempting
11:09 pq: "USB-C:5-2:1.1,HDMI,VGA" for example, to say it's a physical USB-C and which one, using a dongle to convert to HDMI, plus another dongle to VGA. Assuming all that could be known, which I guess cannot always be.
11:11 pq: a proper PATH with physical connector and add-on dongles sounds tempting
11:12 emersion: oh the USB-C sysfs is pretty nice
11:12 emersion: has properties like a "dock" bool
11:12 pq: but I'm afraid I can't get much involved here, too far off of my current work
11:12 emersion: > ls /sys/bus/usb/devices/1-0:1.0/usb1-port1/physical_location/
11:13 emersion: dock horizontal_position lid panel vertical_position
11:14 pq: not sure I even have USB-C personally anywhere
11:14 emersion: i'm not sure baking the subconnectors into the path necessarily makes sense
11:14 emersion: maybe…
11:15 pq: if there is a converter dongle, it's on the signal path, so
11:16 emersion: right, and a converter might have multiple output ports
11:17 pq: sounds more and more like MST
11:17 emersion: so DP → HDMI → VGA should probably have a different path from DP → HDMI → DVI
11:17 emersion: or DP → DVI → VGA
11:17 pq: that would make sense to me
11:18 emersion: (assuming there is a HDMI converter that has either VGA or DVI output here)
11:19 emersion: (or a DP converter which can do either HDMI either DVI)
11:19 emersion: or*
11:19 pq: but if a converter has multiple output ports, then shouldn't each one be exposed as a separate connector? Maybe not, if only one can be used at a time, but how do you then... update the path based on which one is connected?
11:20 pq: assuming the converter even tells us that to begin with
11:20 emersion: what do you mean?
11:20 emersion: KMS props can be updated
11:21 pq: I'm just thinking from end-user perspective: you have a port on the computer, and you plug in a thing that has multiple different types of ports. How do you represent that in UI?
11:21 emersion: ah, so you're saying that ideally we know which availabe ports an adapter has?
11:21 emersion: potentially even before anything is connected?
11:22 pq: ideally yes, but I also wonder if that's feasible at all
11:22 emersion: i'd be surprised if it was
11:22 emersion: i'd be surprised if we can figure out the DP → HDMI → VGA case even
11:22 jannau: I think USB-C/dp-altmode converters with multiple outputs are using DP MST
11:23 emersion: DP-MST has a native concept of tree, but for anything else i don't think so
11:23 emersion: jannau: yeah, we're wondering about non-DP stuff
11:24 pq: the connector prop should be designed around the most flexible/complex case, and anything else that doesn't have all the info just reports whatever
11:24 emersion: agreed
11:25 emersion: (cc lumag, see the whole discussion above)
11:25 zamundaaa[m]: pq: it's not necessarily that easy, as you're requiring everyone to put all the info in from the beginning. You can't change the prop for a given hardware setup if it's used by userspace as a port identifier
11:26 zamundaaa[m]: So if you find out you can get more information later, you'd need yet another property to do that without breaking existing userspace
11:26 pq: true
11:27 pq: so we'd actually need a property with an array of strings, so better ones can be added without deleting old ones... uhh
11:31 pq: that problem is universal though, and always present; we're thinking of a new prop because we can change the old stuff, and that is a one-off fix. Once the new prop becomes broken the same way, we'd need yet another prop for the same reason.
11:31 pq: *we cannot change the old stuff
11:31 lumag: pq, I have a USB-C -> DP and HDMI (two output ports). Only one output ports is detected and works.
11:32 pq: lumag, only one output port ever, or does it switch somehow?
11:32 emersion: pq, yeah
11:32 lumag: If I plug in HDMI and DP, only HDMI is detected
11:32 lumag: and read
11:33 emersion: DRM_CLIENT_CAP could be used to some extent
11:33 emersion: and the kernel can shim the old APIs…
11:33 lumag: So far we have support for single logical connector connected to several physical connectors, think about CONNECTOR_TV and respective subconnector types.
11:33 emersion: hm, but a compositor is not very likely to be able to ever upgrade
11:33 lumag: emersion, why?
11:34 emersion: so yeah, need access to all variants, old and new
11:34 pq: emersion, I wonder if the shimming will need to be per-driver, too
11:34 emersion: lumag: because configuration files store the prop value
11:34 lumag: true
11:35 emersion: pq, could definitely happen yeah
11:35 emersion: driver exposes a short string, then realizes it can expose more
11:35 lumag: emersion, what about exposing USB connectors and a shim DP connectors?
11:35 lumag: Just for AMD and intel
11:36 emersion: what do you mean by "shim" exactly?
11:36 lumag: lightweight aliases
11:36 lumag: I haven't looked into corresponding drivers though.
11:36 emersion: so user-space would see DP for Intel/AMD?
11:36 emersion: but USB for everybody else?
11:37 emersion: that doesn't sound great
11:37 lumag: emersion, so user space would see USB for everybody, and aliasing DP for intel/AMD
11:37 emersion: we could have CLIENT_CAP_USB_CONNECTOR or so
11:37 emersion: so user-space would see two connectors, one USB and one DP, which are actually the ame?
11:37 emersion: same*
11:37 lumag: yep
11:37 emersion: that sounds like it would cause many issues
11:37 zamundaaa[m]: it definitely would
11:38 gfxstrand: karolherbst: Yes, lower_var_copies needs something. I think what it needs is a threshold at which it emits memcpy().
11:38 emersion: user-space would not know these are the same, and would try to drive each indepdendantly
11:39 gfxstrand: karolherbst: Hrm... Actually that might not be tractable...
11:39 gfxstrand: It probably needs a loop threshold instead
11:39 lumag: true
11:40 lumag: emersion, pq: I don't like the idea of 'path' including the USB path. It might change from boot to boot.
11:40 zamundaaa[m]: emersion: regarding CLIENT_CAP_USB_CONNECTOR, that would not be a good idea. We need the old identifier as well as the new one
11:41 emersion: lumag: really?
11:41 pq: lumag, USB path is not a physical path?
11:41 emersion: i thought usb path was physical
11:41 lumag: emersion, pq. it includes bus id. And bus id can change depending on the probe order
11:41 pq: well, replace that with something that is a physical path
11:42 emersion: ah, reminds me of https://lore.kernel.org/dri-devel/20230228151654.6175.qmail@stuge.se/
11:42 emersion: "The bus on each new host controller gets the next available bus number."
11:42 lumag: yes
11:43 emersion: that's a good point
11:43 emersion: lumag, do you know if there is something else which doesn't change?
11:43 emersion: something to represent a purely physical path for USB?
11:44 lumag: emersion, no. We can create 'something', but it will not map to the actual system property.
11:44 lumag: VID/PID do not change, but then we don't have a clear way to distinguish between several similar dongles
11:44 lumag: typec path?
11:45 emersion: we'd want something to identify "the upper-left USB port on this USB dongle"
11:45 emersion: which doesn't change
11:45 lumag: emersion, the problem is that there can be no _USB_ in case of a DP dongle
11:46 emersion: AFAIK DP has such a concept
11:46 lumag: which one?
11:46 emersion: "the upper-left DP port on this DP dongle" as a stable identifier
11:47 emersion: or maybe not and we've misunderstood the PATH prop the whole time?
11:47 emersion: (also cc vsyrjala)
11:47 jannau: device tree based systems might have labels on ports, the apple silicon systems all have something like 'label = "USB-C Left Front";" the usb-c/4 ports la
11:48 emersion: jannau: is this exposed via sysfs with "physical_location" i mentioned earlier?
11:49 lumag: emersion, what about something completely different for the DP: something like 'protocol' or 'bearer'. Which can be 'native', 'USB' or 'HDMI' (only for dual-mode ports)
11:49 lumag: pq ^^
11:50 gfxstrand: karolherbst: Okay, I've added a max unroll length to lower_var_copies as well
11:50 pq: are we trying to solve the path problem (which has value in its own right), or just the connector type problem without path?
11:50 emersion: in the case of HDMI, the subconnector would be HDMI already i think?
11:50 jannau: I think all usb-c dp-altmode converters expose a BILLBOARD usb device
11:50 gfxstrand: karolherbst: It's not amazing on arrays of arrays but it's better than what we have now
11:51 emersion: pq, well they interact somewhat, so trying to see if there's a good solution to both, or if the solution should be separate
11:51 lumag: jannau, not all
11:51 pq: yes, I too think they interact
11:51 lumag: it is an option, not a requirement
11:52 lumag: and in some cases they disappear after DP altmode being negotiated
11:53 pq: and I suspect that solving path would be an answer to the type question, but not vice versa.
11:53 emersion: yes
11:54 zamundaaa[m]: I don't think having the connector type in the path would be important. All I want to use the path for is as a fallback when monitors have broken EDID
11:54 jannau: I don't see the label exposed in obvious places in /sys
11:54 emersion: my immediate goal is to be able to expose strings such as "Samsung SyncMaster via HDMI and USB-C Left Front" to users
11:54 zamundaaa[m]: For me, the connector name is only relevant because it gets shown to the user. Other than that I don't care about it
11:55 emersion: you can hide it from the user if you can figure out that it's USB-C
11:55 zamundaaa[m]: emersion: if we can get nice computer-side port names that would be great. I have doubts we can get that on most hardware though
11:55 emersion: zamundaaa[m]: jannau said it's in device tree at least
11:56 lumag: emersion, it is not required.
11:56 emersion: sure
11:56 lumag: We don't have labels on msm
11:56 emersion: but when it's here, nice to show to users
11:56 lumag: emersion, I don't think it is a part of DT spec
11:56 lumag: or schema
11:58 pq: If one can tell an end user which port a thing is a la "third from the left, in the back" etc. then that in itself is a persistent port ID, and therefore equivalent to a path. But the information does not always exist.
11:59 pq: Sounds like we have three different things: path, end-user location, and connector type.
11:59 zamundaaa[m]: Should these two things maybe be split? One thing for showing to the user, explicitly not guaranteed to be persistent, and one actually persistent ID with compatibility guarantees
11:59 jannau: lumag: it is part of bindings/connector/usb-connector.yaml
12:00 lumag: jannau, ack, excuse me then
12:00 emersion: i don't think we'd want KMS to generate end-user strings
12:00 lumag: I remembered krzk removing some of the labels from 410c DT
12:00 zamundaaa[m]: Not end user strings, just a path that the compositor can convert into usable (and translated) strings
12:00 emersion: these can be generated by the compositor from just the USB ID
12:00 lumag: if there is a usb ID
12:01 emersion: there is always a USB ID for USB devices
12:01 lumag: emersion, if there is a USB device
12:01 zamundaaa[m]: emersion: a split would be important imo because then you can add user-visible information later on, without breaking config files
12:01 emersion: lumag: sure
12:01 lumag: I have dongles w/o USB
12:01 lumag: or with the USB disconnecting after altmode is negotiated
12:02 emersion: that's a fun one
12:04 lumag: emersion, it is a part of DP capabilities VDO:
12:04 lumag: 7
12:04 lumag: USB r2.0 Signalling Not
12:04 lumag: Used
12:04 lumag: 0 = USB r2.0 signaling may be required on A6 – A7 or B6 – B7 while in DisplayPort
12:04 lumag: Configuration.
12:04 lumag: 1 = USB r2.0 signaling is not required on A6 – A7 or B6 – B7 while in DisplayPort
12:04 lumag: Configuration.
12:05 emersion: so hm
12:06 emersion: from the start when i said "USB device ID" what i really thought of was "USB port ID"
12:06 lumag: I think you meant 'typec port id'
12:06 emersion: ie, if a USB-C port is disconnected, some unique identifier for this port
12:06 emersion: yeah, maybe
12:06 lumag: But I'm not sure whether amd and intel drivers maintain such link
12:08 emersion: so
12:08 emersion: https://lore.kernel.org/dri-devel/20221108185004.2263578-1-wonchung@google.com/
12:08 emersion: ^ what this does is link to the device, right? not the port?
12:08 lumag: Yes
12:09 emersion: so the link doesn't exist if there is no connected device?
12:09 lumag: And single device can have two ports
12:09 lumag: s/two/multiple/
12:09 emersion: … wait, what? :o
12:09 lumag: E.g. I have:
12:09 lumag: lrwxrwxrwx 1 root root 0 Aug 12 23:47 /sys/class/typec/port0 -> ../../devices/platform/USBC000:00/typec/port0
12:09 lumag: lrwxrwxrwx 1 root root 0 Aug 12 23:47 /sys/class/typec/port1 -> ../../devices/platform/USBC000:00/typec/port1
12:10 lumag: there is a single UCSI device, two USB-C ports.
12:10 lumag: (for the reference, Lenovo p53s)
12:10 emersion: what is UCSI?
12:10 lumag: A spec for the ACPI Type-C port configuration and management
12:11 emersion: but in the specific case of USB for displays, can this happen stiull?
12:11 lumag: see drivers/usb/typec/ucsi/
12:11 lumag: Yes. Both USB_C ports are capable of a DP
12:11 emersion: can i connect my screen with 2 USB-C cables?
12:11 emersion: will this show up as one KMS connector, or 2?
12:12 emersion: so it's not a tree, it's a graph?
12:13 lumag: Hmm, if you connect your monitor using two cables, you'll see two different connections.
12:13 lumag: For example, here I have:
12:13 emersion: which means two KMS connectors?
12:14 lumag: DP-1 - port0 'native' DP
12:14 lumag: DP-2 - port1 'native' DP
12:14 emersion: okay, phew
12:14 lumag: DP-1-1 / DP-1-2 / DP-1-3 - port0 'docked' DP connections
12:14 emersion: i was reconsidering my life choices for a sec
12:15 emersion: what's important to me is that one KMS connector maps to a single USB-C port
12:15 lumag: Yes
12:15 emersion: *each KMS connector
12:16 emersion: alright, so to sum things up a bit, a think we have the following options:
12:16 emersion: - add a "USBC_PORT" prop, backwards compatible, need to check amd/i915
12:17 lumag: emersion, sounds good to me
12:17 emersion: - add USB connector type, needs DRM_CLIENT_CAP_USB_CONNECTOR, doesn't expose the USB-C port so not enough for all use-cases
12:18 emersion: - figure out a way to expose a PATH prop, needs a lot more investigation, not sure possible at all
12:18 emersion: (plus these backwards compat questions)
12:19 emersion: lumag: additional question, how useful is the USB-C port? i'd assume i can walk the tree from there, discover connected USB devices, etc?
12:19 lumag: emersion, yes
12:20 emersion: cool
12:20 zamundaaa[m]: ohh then we could maybe detect if a touchscreen is connected to a given screen?
12:20 lumag: https://pastebin.com/Suuhzji9
12:20 emersion: aha
12:20 lumag: emersion, https://pastebin.com/Suuhzji9
12:21 emersion: zamundaaa[m]: i think it depends on a lot of stuff
12:21 emersion: like, if you have a USB hub…
12:21 lumag: emersion, the port itself is not a part of the USB topology
12:21 emersion: for that use-case you'd maybe be more interested in the USB device
12:21 lumag: it lists two USB busses
12:22 lumag: s/busses/routed ports/
12:22 emersion: not 3?
12:22 lumag: emersion, compare this with https://pastebin.com/SHJvbPLh
12:22 emersion: port0.0, port0.1, port0.2?
12:22 lumag: No. port0.0, port0.1 and port0.2 are altmodes
12:22 emersion: i see
12:23 lumag: /sys/class/typec/port0/port0.0/svid:17ef
12:23 lumag: port0.0/svid 17ef
12:23 lumag: port0.1/svid 8087
12:23 lumag: port0.2/svid ff01
12:27 lumag: emersion, I'd say:
12:27 lumag: - we need connector -> type-c sysfs port link
12:28 lumag: - probably the best option would be to encode type-c port into PATH property.
12:28 emersion: i don't think we can re-use PATH here
12:28 emersion: already used by DP-MST
12:28 lumag: (unless it breaks userspace expecting stuff like 'mst:103-2')
12:29 lumag: "Connector path property to identify how this sink is physically connected."
12:29 lumag: But I'm not sure if 'typec:1' will break userspace expecting 'mst:foo'
12:29 emersion: also is the typec port number persistent?
12:29 emersion: or can it change across reboots/upgrades?
12:29 lumag: On devices I have here it is persistent
12:29 emersion: lumag: what if there is typec *and* DP-MST
12:30 lumag: heh, mst:103-2 is such example
12:30 lumag: connector '103' is the base connector
12:31 emersion: hm.. do you mean '103' is the KMS connector ID, or something else?
12:32 emersion: KMS connector object ID, i mean
12:33 lumag: yes, connector ID
12:33 lumag: https://gitlab.freedesktop.org/xorg/xserver/-/blob/master/hw/xfree86/drivers/modesetting/drmmode_display.c#L3238
12:33 lumag: xorg will silently skip PATH if it doesn't start with 'mst:'
12:35 mceier: lumag: the function that calls parse_path_blob has other fallbacks - https://gitlab.freedesktop.org/xorg/xserver/-/blob/master/hw/xfree86/drivers/modesetting/drmmode_display.c#L3278
12:35 emersion: it doesn't seem so
12:35 emersion: example: https://drmdb.emersion.fr/snapshots/63e8a55fb9dd
12:35 emersion: Connector 5 with object ID 114 has "mst:92-1"
12:35 lumag: yes, which tells that it is going through Connector 1 (with ID 92)
12:35 emersion: eh, but 92 is another connector…
12:36 emersion: ouch…
12:36 emersion: that means it's not a stable identifier at all
12:36 emersion: pq ^
12:36 lumag: well, connector IDs are stable in 99% of cases
12:36 emersion: hm no
12:36 lumag: why?
12:36 emersion: upgrades create new props, which share the same namespace, for one
12:36 emersion: driver probe order
12:37 emersion: etc
12:37 lumag: Ah.
12:37 lumag: driver probe order will not change it, since each device has its own namespace
12:37 emersion: okay, that makes PATH mostly useless
12:38 lumag: But for the new props, it's true
12:38 emersion: hm, possible
12:38 emersion: i don't remember
12:38 lumag: I'd say, PATH is semi-dynamic.
12:38 lumag: In other words it can not be used as a static reference, but it can be parsed to produce one.
12:38 emersion: that's not a good thing to store in a config file
12:38 emersion: hm
12:39 emersion: but what are the numbers after the parent connector ID?
12:39 lumag: emersion, that's why xorg parses it to produce sensible names
12:39 emersion: are these dynamic or not?
12:39 lumag: MST port number
12:39 lumag: static
12:40 emersion: ok, nice
12:40 lumag: On the devices i have here it corresponds to the physical port
12:44 lumag: emersion, I'd say PATH = 'typec:%d' solves our issues.
12:44 emersion: i don't think so
12:45 lumag: We can parse it and then generate 'USB-DP-%d' connector names
12:45 emersion: a connector can be both Type-C and DP-MST
12:45 lumag: Then the base connector will have Type-C and next connector will be DP-MST
12:45 emersion: to not regress user-space, PATH needs to be "mst:<something>" for all DP-MST connectors
12:45 emersion: hm
12:45 emersion: i see
12:46 lumag: In my case I'll have DP-1 with PATH='typec:0', and DP-4 / DP-5 / DP-6 with PATH='mst:103-#'. Xorg then renames DP-4/5/6 to DP-1-1, DP-1-2, DP-1-3
12:47 lumag: And correspondingly DP-2 with PATH='typec:1' (or vise versa) and DP-something renamed to DP-2-1, DP-2-2, etc.
12:47 lumag: The only issue I foresee is SlimPort, the legacy/obsolete DP-over-micro-USB.
12:47 emersion: that sounds good to me, with the caveat that i don't understand things deeply enough to say for sure whether this is a good use of PATH, or an abuse
12:48 emersion: well this one would be completely different no?
12:48 emersion: i don't know if anyone cares enough to address it
12:49 emersion: by "completely different", i mean probably PATH with "usb:<something>"
12:49 lumag: emersion, yep
12:49 lumag: at least it sounds logical then
12:50 emersion: and the same would apply for other display-over-older-USB things
12:50 lumag: It is supported by drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c, which I hope to try on Nexus7-2013 at some point
12:50 emersion: like GUD
12:50 lumag: ok.
12:50 lumag: I can then scratch an RFC during the weekend and send it to dri-devel
12:50 emersion: nice
12:50 emersion: i can write the user-space
12:51 lumag: :-)
12:51 lumag: mceier, yes, but the fallbacks are basic - type + index (not the object ID)
12:52 emersion: mceier, i don't see your message
12:52 mceier: lumag: yes, you can ignore me, since I donn't really know the context ;)
12:52 lumag: emersion, it was '<mceier> lumag: the function that calls parse_path_blob has other fallbacks - https://gitlab.freedesktop.org/xorg/xserver/-/blob/master/hw/xfree86/drivers/modesetting/drmmode_display.c#L3278'
12:52 emersion: and now i do
12:52 emersion: oh, in the backlog - nevermind!
12:53 emersion: i thought this was another case of matrix users
12:53 mceier: :)
13:14 lumag: jani, jannau, emersion, airlied: another DP-related topic. I'm trying to understand a way for https://patchwork.freedesktop.org/series/120395/ to land.
13:16 lumag: It is core + intel, but it is required to enable additional part of DP on msm platforms
13:30 pq: emersion, PATH property for DP-MST is not persistent at all? Whee. Well, it just means more parsing, don't simply save the PATH string as-is. Replace the conn ID with a proper path.
13:34 karolherbst: gfxstrand: cool, will give it a try. I have a few patches around to reorder some of the lowering, because I'll need it for program variables as well. Anyway, seems to work either way now.
13:41 alyssa: Do we have any common code for handling ADJACENCY in the absense of a geometry shader?
13:41 alyssa: other than nir_create_passthrough_gs, I guess
13:49 alyssa: hmm, gl-3.2-adj-prims passes, I wonder why the CTS doesn't
14:46 dottedmag: How is GBM_BO_USE_RENDERING really used? In libgbm DRI backend the only use of this flag is to check that GBM_BO_USE_CURSOR and GBM_BO_USE_RENDERING are not specified at the same time.
14:58 alyssa: got it. 2 bugs in nir_create_passthrough_gs,
15:04 alyssa: MR coming soon
15:05 alyssa: kusma: zmike: It looks like nir_create_passthrough_gs wants the VS/TCS but doesn't actually use it, it just uses the shader info
15:05 alyssa: Is there a compelling Zink reason it's done like this?
15:05 zmike: you'd need to ask pac85 but he's not on irc
15:05 alyssa: Why should the passthrough GS be tied to the shader, as opposed to just the context/screen?
15:05 alyssa: who is pac85?
15:05 alyssa: kusma wrote this code
15:06 zmike: antonino
15:06 zmike: just create a ticket
15:06 alyssa: Alright
15:07 alyssa: It looks like it would be sufficient to pass in (outputs_written, has_transform_feedback_varyings, xfb_stride, xfb_info) instead of the whole shader
15:07 zmike: could be
15:07 alyssa: in the common case where there's no GS that's just outputs_written
15:07 zmike: on my side there's no requirement for it being the way it is
15:08 alyssa: which means you can reuse passthrough GS's for unrelated VS's as long as they write the same outputs
15:08 alyssa: which seems.. potentially good?
15:08 zmike: but this is emulation code that I don't (personally) support or deal with so you'll want to ask in the ticket
15:08 alyssa: yeah fair enough
15:08 alyssa: I'm considering the incredibly dubious choice of using a passthrough GS anytime XFB is used
15:08 alyssa: but I digress :~P
15:10 alyssa: oh, hm, this might be tricky without lowered I/O though
15:11 alyssa:may fork create_passthrough_gs for a lowered I/O-only version if this can't be fixed with derefs
15:11 zmike: just convert it to lowered io?
15:13 alyssa: oh that MR landed, nice :)
15:16 zmike: the only caveat, as I replied, is that variables/types do have to exist and be correct
15:16 zmike: which is probably not a huge ask?
15:16 zmike: but who knows what your needs for this are
15:17 alyssa: certainly I don't
15:22 alyssa: Hmm
15:22 alyssa: Now I'm wondering if it wouldn't be better to handle adjacency in the VS
15:23 alyssa: meh, this is a totally stupid edge case that apps won't hit, not worth the combinatorics
15:41 DemiMarie: pq emersion: from a security perspective, Qubes really wants physical paths determined by where a user plugged in their device, so that a malicious device cannot spoof another device.
15:42 emersion: not sure i understand the threat model
15:43 emersion: lumag: ah btw IGT expects "has PATH prop == DP-MST"
15:43 emersion: would be nice to stop making that assumption
16:07 alyssa: can I solicit some NIR review for https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24616 and https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24743
16:07 alyssa: please & thank u
16:19 DemiMarie: emersion: Qubes OS considers external peripherals, such as USB devices, to be untrusted by default (that’s why we have sys-usb). Ideally DisplayPort alt mode would be limited to trusted devices, though that is not currently implemented. For it to be possible to implement, though, the ID needs to be something a malicious device can’t spoof, as otherwise a malicious device could impersonate a trusted one.
18:07 idr: Anyone have issues with 'ninja test' hanging in 'mesa:util / util_tests'?
18:54 DavidHeidelberg[m]: idr: do you have today `main`?
18:55 idr: Yeah... and I can reproduce it on my main system back over 1000 commits.
18:56 idr: But it only seems to happen on that system.
18:56 DavidHeidelberg[m]: https://gitlab.freedesktop.org/mesa/mesa/-/issues/9222
18:56 DavidHeidelberg[m]: this issue or different one?
18:56 idr: hm...
18:57 idr: Different, but possibly related.
18:57 idr: It looks like it times out in SparseArrayTest.Multithread.
18:58 idr: So, maybe not related... unless the cache test is also multithreaded.
19:09 idr: There is something janky going on.
21:46 idr: DavidHeidelberg[m]: Reverting glibc from glibc-2.37.9000-14.fc39 to glibc-2.36-9.fc37 has "fixed" the problem.
21:48 DavidHeidelberg[m]: ugh, some extra Fedora patches or just the glibc bump to 2.37?
21:49 idr: Dunno.
21:49 idr: I have a commit that also "fixes" it, but it make it run much more slowly on systems that don't have the problem.
21:52 idr: DavidHeidelberg[m]: https://gitlab.freedesktop.org/idr/mesa/-/commit/394272244d7ea441bc19b63fbebc6e99b7081001
21:55 HdkR: https://sourceware.org/bugzilla/show_bug.cgi?id=30723 Known regression in glibc I'm pretty sure
21:56 DavidHeidelberg[m]: ^ then I guess we just have to wait a week or two for this issue to disappear hopefully?
22:29 DavidHeidelberg[m]: zmike: KHR-GL46.layout_binding.sampler2D_layout_binding_texture_ComputeShader took down by `free(): unaligned chunk detected in tcache 2` is that something you aware?
22:29 DavidHeidelberg[m]: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/47690485
22:29 zmike: it's been on my list but the list is long
22:48 idr: HdkR: That sounds very much like the issue.
22:48 idr: I'm glad that I didn't have to try to write a good bug report for it. :)
22:49 idr: Wow... DJ Delorie is a name I haven't heard in many years... since I did DOS programming in the mid 90s.
22:51 HdkR: Somewhat luckily I was pointed to that issue just a day or two ago
23:00 DavidHeidelberg[m]: zmike: u know, that's enough, worth adding into flake list?
23:00 zmike: suer