09:18 luc: hi, what's the difference between window_modifiers and screen_modifiers in xcb_dri3_get_supported_modifiers_reply_t? with a quick search in xserver code, i found window_modifiers returned from ->get_drawable_modifiers() which seems like to be implemented only by glamor. i wonder what purpose exactly another set of modifiers needs to be provided in
09:18 luc: glamor.
09:25 MrCooper: luc: in a nutshell, screen_modifiers is that the drivers support in general, whereas window_modifiers can be a subset of that which changes dynamically, e.g. to allow direct scanout
09:26 MrCooper: err, s/that/what/ for the first instance
09:35 luc: MrCooper: thanks
09:38 pq: What do people think about storing userspace virtual addresses in KMS blobs for kernel driver access? The "Display Global Histogram" series seems to use them.
09:44 pinchartl: pq: in my experience, when it comes to passing userspace pointers, proper design is needed to create good APIs. KMS blobs are still documented APIs, even if they may get less scrutiny than ioctls
09:44 pinchartl: it could be worse, I've seen (out of tree) drivers passing physical addresses from unpriviledged userspace
09:49 pq: pinchartl, I was kinda expecting to hear "don't do that".
09:50 pq: who knows what the lifetime of the blob is, so it's impossible to make sure the life time of the pointed to virtual memory is good.
09:50 pinchartl: I don't *like* the idea much, but I also have no really strong argument against it
09:50 pinchartl: true, but you'll have the same issue with ioctl arguments
09:50 pinchartl: it's inherent to user pointers
09:50 pinchartl: or was your question about whether or not we should use user pointers in APIs in the first place ?
09:51 pq: usually once the ioctl returns, the address is no longer used nor stored anywhere, right?
09:52 pinchartl: we have an API in V4L2 where you can queue a buffer to capture a video frame, using a userspace pointer
09:53 pinchartl: that's been deprecated a while ago, but it's still exists
09:53 pinchartl: I refuse new drivers using that API
09:53 pinchartl: so I'd say it's bad practice, yes
09:53 pq: cool.
09:53 pinchartl: maybe pass a GEM handle instead ?
09:53 pq: dunno
09:54 pq: the series has two uses: user->kernel has no reason to use user pointers, one could just put the pointed-to data into the blob.
09:54 pq: kernel->user for returning the histogram is more interesting
09:55 pinchartl: for user->kernel, true as long as the data isn't too big. if we're talking about MBs of data the copy can cause a performance impact
09:55 pq: nope, doesn't seem it would be 100s of bytes
09:56 pq: even
09:56 pinchartl: does this essentially queue a command to tell the device to calculate a histogram, with the histogram data being returned asynchronously ?
09:56 pq: pretty much, yeah, I think there is some kind of an event to tell when it's ready
09:57 pq: it's a pixel value histogram of a KMS output (CRTC)
09:58 pinchartl: a buffer whose lifetime is managed by the kernel would seem more appropriate
09:58 pq: yeah
09:58 pinchartl: depending on the size of the histogram, the data could even be copied by DMA
09:58 pinchartl: so you don't want that memory to just be malloc'ed by userspace
10:02 pq: I think the histogram size in this one specific case is limited to 256 kB, but other modes could be added later.
10:03 pinchartl: even 256kB isn't negligible if you do it for every frame
10:11 sima: pq, you can't do that
10:12 sima: I guess I'd need to reply there, do you have a link?
10:13 sima: it's also kinda not doable with out-blobs, because blobs are immutable
10:13 pq: sima, I just sent my reply now, I can dig the link
10:13 sima: blob properties aren't necessarily immutable, but we do mutability by changing the entire blob
10:14 pq: https://lore.kernel.org/dri-devel/20250217120808.708b9b4d@eldfell/
10:17 emersion: i'm interested in your reply sima :P
10:18 pinchartl: emersion: please share the popcorn
11:10 pq: I think something in my lei filter doesn't work.
11:17 pq: emersion, I think all my wildcard expressions in my lei search are broken.
11:25 pq: Looks like matching for dfn:include/uapi/drm/drm_* just isn't possible.
11:39 pq: emersion, FYI, if the lei search string is broken, you just get silently no hits.
13:23 picosaurus: and such system is not very hard to design, your IO is accessed from memory or registers and at the moment it's done userspace does nothing with this memory or registers, in other words as the hardware became more powerful compared to eighties and before, entirely secure systems design also became different but is lot easier due the fact, overengineering was needed only with small
13:23 picosaurus: resources to be more exact.
13:44 sima: emersion, tldr; I think memfd properties. everything else I've pondered has more or less fundamental issues
13:45 sima: but it's a longer mail, still need to type it up, and I haven't even gotten to lunch today yet
13:49 emersion: memfd properties?
13:50 sima: like blob properties, except it's a memfd
13:50 sima: can be sealed, so no surprises with wrong size
13:50 sima: could be r/o sealed too if wanted
13:51 sima: already has mmap for zero copy
13:51 sima: and thanks to udmabuf there's memfd pin support, so also no work needed to map them kernel side
13:51 sima: but the full mail needs to walk through all the other options and why they're worse
13:52 sima: and the uapi questions we need to nail for memfd properties
14:52 pinchartl: sima: does that preclude DMA'ing the histogram data to the buffer then ? isn't that a problem ?
14:52 sima: well if you dma into it, then maybe a gem_bo is the better thing
14:53 pinchartl: if the histogram is large-ish, I'd expect the hardware to have DMA support, so it would be good to design the API in that way
14:54 pinchartl: could be a GEM BO, or even a framebuffer. we likely don't need multi-plane support, but it could still be nice to standardize FB as being the object passed through KMS atomic commits, instead of passing GEM BOs (or do we already use GEM BOs that way?)
14:56 sima: nah it's all drm_fb
14:56 sima: gem_bo are not great because for many drivers they're wc, and that's absolutely not what you want for readback to the cpu
14:57 sima: and so we'd have random non-wc gem_bo in there if we do this, which could lead to all kinds of surprises
14:57 sima: like we couldn't reject those at prime import time or addfb time anymore
14:57 sima: unless we add a pile of special cases and flags
14:59 sima: pinchartl, I guess using a drm_fb and allowing memfd backed drm_fb might work
15:00 sima: and then drivers need to check that they only allow the memfd stuff on histogram formats
15:00 sima: still feels yucky to no end
15:01 stsquad: if I want to track all the allocated buffer objects by their userspace address where would be the best place to put a tracepoint?
15:02 pinchartl: but memfd-backed drm_fb wouldn't allow DMA
15:21 sima: pinchartl, they're separate use-cases
15:21 sima: depending upon what your hw can do
15:22 sima: stsquad, drm_gem_create_mmap_offset() as a one-shot maybe? and then use mmap() tracepoints to figure out where it landed
15:22 sima: it's a bit indirection, so you need to piece it together with post processing
15:23 sima: or maybe don't even bother with one-shot, if userspace calls this multiple times it's kinda broken anyway, no point making this more complicated
15:23 sima: stsquad, might also have some other missing tracepoints for just basic gem buffers, not sure about that
15:29 stsquad: sima grepping seems to imply that ttm buffers share the gem buffer tracking data underneath - so I guess tt_bo->base->vma_node->drm_mm_node->start?
15:31 sima: yeah, they should probably all end up in the same helper function I pasted
15:31 sima: maybe not vmwgfx, but that's super special anyway
15:31 sima: otoh I think even vmwgfx isn't that special anymore
15:31 stsquad:looks at drm_trace.h
15:32 sima: I just don't want to have more driver specific tracepoints for stuff like this where we managed to unify it pretty well
15:32 stsquad: sima this is only for my internal debugging, just trying to keep it neater than a bunch of kprintfs and so I can turn them on and off again ;-)
15:33 sima: ideal world and all that ofc
15:33 sima: stsquad, ah, well I can still hope that more good tracing infra is being built on upstream and shared across driver teams and users :-)
15:33 sima: pepp, ^^ maybe of interest to you too
15:35 stsquad: I can certainly post my tree status for reference once I've understood whats going on - this is working around broken PCI anyway
15:47 pinchartl: sima: as long as the API is based on a drm_fb, then it can be backed by GEM BOs, memfd or something else
15:58 sima: alyssa, just noticed the apple touch bar driver got a bit stuck, I guess you need to resurrect drm-misc commit rights
15:59 sima: and figure out with bentiss how to handle the cross tree aspect
16:01 alyssa: sima: uhhh alright
16:01 sima: alyssa, maybe also coordinate with drm-misc maintainers here depending if you need a topic branch, but usually we try to avoid these
16:04 alyssa: i'm not really sure who to pin gabout what here
16:04 alyssa: feels like I'm jumping into the deep end, lol
16:04 sima: yeah
16:05 sima: since it's a patch set spanning hid and drm you get three options a) land in hid through bentiss, some drm maintainer acks b) in drm-misc, bentiss acks c) topic branch (drm-misc maintainers can wrangle that for you) and merge into both
16:05 sima: and drm-misc maintainers are tzimmermann mripard and mlankhorst here
16:05 sima: a or b preferred since less work
16:06 alyssa: sima: I'm not sure I see the need for the complexity here
16:06 tzimmermann: alyssa, sima, for a simple driver with little dependencies, you'd have my ack to merged it through hid
16:06 alyssa: the touchbar support is 2 separate series
16:07 alyssa: 1 is a DRM driver for the display, 2 is a HID driver for the touchscreen
16:07 tzimmermann: although drm moves faster than hid; so merging through drm might be easier
16:07 chaos_princess: yea, there is no need to merge it all at the same time, just merge it at all somehow
16:07 jannau: I'm not aware of functional dependencies between touchscreen and display so merging them independently shouldn't be a problem
16:07 alyssa: merging the DRM driver through drm-misc and the input through HID seems simplest
16:07 tzimmermann: sounds good
16:07 alyssa: I can try to figure out how to use dim enough to push the DRM side
16:09 sima: ah yeah if there's no functional dependency then even easier
16:15 jannau: what's maybe missing are hints to link touchscreen and display. user space currently knows which devices to use which is not much of an issue if there are just a handful devices (was going to say 2 but then remembered that intel macbooks with tiouchbar exists)
16:24 sima: jannau, sysfs links are usually used for that
16:42 sima: mripard, bridge state stuff looks good up to the added pointers in bridge states, from there I'm not entirely sure
16:42 sima: dropped some comments and big thanks dmitry for reviewing almost all of it
16:43 sima: (yeah forgot the right nick just now)
16:43 sima: (does irc have a search to find nicks by name)
16:48 mripard: lumag: ^
16:48 mripard: sima: thanks :)
16:51 colinmarc: I'm using syncobj timelines (as a wayland compositor) and doing the following dance to import them as a vulkan sempahore:... (full message at <https://matrix.org/oftc/media/v1/media/download/AbtwKxqJk-ZO8TaVSQmOVdUUM5CNPHmm6e39j8Rn7TEdZ7gmMD0mXrR_yZtwfMwSipnJIKv4-bea7Lw6iO6GaspCeVXOuk9QAG1hdHJpeC5vcmcvV0lpR21ZdHhrZlNodWxKWWhMVXdiWUpx>)
16:52 colinmarc: (are syncobjs on-topic here? sorry if not)
16:53 sima: tzimmermann, thx for the ivpu discussion, just dropped my +1
16:55 sima: tursulin, I guess I owe you lunch or something at next conference for sched kunit tests, thanks a lot :-)
16:56 tzimmermann: sima, sure. thanks for the reply. it looks like things might get better
16:57 pinchartl: mripard: if you feel brave, you could s/drm_atomic_state/drm_atomic_commit/ :-)
16:57 mripard: pinchartl: I've been brave already: I added it as a TODO entry
17:01 mripard: someone publicly forced me into writing doc a long time ago, I guess old habits die hard :)
17:02 sima: tursulin, https://lore.kernel.org/dri-devel/20250214203757.27895-4-jonathan.cavitt@intel.com/ this one looks really bad to me, cc'ed you on my reply
17:03 sima: dakr, Lyude, karolherbst kinda no bw to type a nice mail to karol's resignation letter, so just thanks for the work, understanding for quitting and an ack here
17:03 sima: and I guess one of you three lands this through drm-misc
17:04 dakr: sima, my plan was to pick it up, once I got an ACK from Steven or Masami to take it through drm-misc.
17:04 sima: dakr, sounds good
17:05 colinmarc: <colinmarc> "(are syncobjs on-topic here..." <- user error 😓
17:27 sima: colinmarc, yeah
17:47 preliminarywalkover: Are we going forward with my design instead :D? Yeah doubtful. Karol's tasks were pretty even very complex in fact but in this todays world, not even smallest chips need anything more than opencl 1.2 paradigm. Same goes to power usage like scaling the power up of the gpu etc. He chose or was given tasks that nobody needs, the community has always been harch though, still a pitty
17:47 preliminarywalkover: to hear he had burned out.
18:24 zf: <pendingchaos> zf: try also doing RADV_DEBUG=nocache with spirv or preoptir < it doesn't seem to have helped :-(
18:31 zf: there's not some other cache I need to disable, is there?
18:33 mi6x3m: hey, can someone tell me how vk_Result_to_str is generated? I get an undefined ref for it
18:33 zf: MESA_SHADER_CACHE_DISABLE=true doesn't seem to have an effect either
19:01 sima: emersion, pq enjoy
19:32 pinchartl: mripard: sorry about that. I'm still grateful for the result :)
19:44 DragoonAethis: FYI: The Intel kernel CI will soon start requiring emails to be allowlisted for CI to proceed with your patches (you'll get 'LGCI.VerificationFailed' in Patchwork if not allowlisted). While we have most common company domains allowlisted, your private addresses might not be, so PM me with your email address to add to the list if needed. Sorry for the extra annoyance :/
20:10 DemiMarie: pinchartl: sorry for the off-topic, but how common is UVC vs IPU in laptops nowadays? I'm trying to figure out if the lack of IPU entries in Qubes OS HCL reports is selection bias.
20:14 pinchartl: DemiMarie: I don't have numbers, but I'd expect UVC >> IPU
20:14 pinchartl: if you find a reliable source of data, I'm interested
20:15 FL4SHK[m]: what are UVC and IPU?
20:15 DemiMarie: pinchartl: That's good to know. Do you know what caused IPU to be a flop?
20:15 DemiMarie: FL4SHK: USB Video Class vs Image Processing Unut
20:15 FL4SHK[m]: hmm okay
20:15 FL4SHK[m]: So like, for the GPU?
20:16 pinchartl: FL4SHK[m]: USB webcam vs. raw sensor connected to an in-SoC ISP
20:16 DemiMarie: Intel's Image Processing Units have had poor Linux support.
20:16 FL4SHK[m]: ahhhh
20:16 FL4SHK[m]: gotcha
20:16 FL4SHK[m]: Interesting, usually Intel is pretty good about the Linux support
20:16 pinchartl: historically webcams integrated in laptops were just USB devices, exactly like an external USB webcam
20:16 FL4SHK[m]: oh
20:16 FL4SHK[m]: huh
20:17 pinchartl: but for a few years now, some vendors have tried to use a raw camera sensor connected to the CPU chip using MIPI CSI-2, with image processing in the chip using a dedicated image signal processor
20:17 DemiMarie: One of the reasons I asked is that a USB GPIO expander is going to be a nightmare in Qubes OS, as the VM with the USB controllers doesn't have access to ACPI tables and visa versa.
20:17 pinchartl: IPU is the Intel name for that ISP
20:18 pinchartl: DemiMarie: as for IPU being a "flop", I'm not sure I'd put it that way, but lack of care for Linux is certainly part of the reasons why it's not universally loved
20:18 DemiMarie: It is much simpler if hardware where ACPI references USB is rare enough to ignore.
20:18 pinchartl: it was designed for windows initially, Linux support was retro-fitted
20:19 pinchartl: as for USB GPIO expanders
20:19 pinchartl: I expect you'll see more of them
20:19 pinchartl: on machines with an IPU
20:19 DemiMarie: Is this because it saves expensive CPU/PCH GPIOs?
20:20 DemiMarie: Is this on a dedicated PCI USB controller or is it the same USB as everything else?
20:21 DemiMarie: pinchartl: Is Intel not being willing to provide open userspace the main problem, or would it be a nightmare even if everything was open?
20:23 pinchartl: if things were open, we'd be fine
20:23 pinchartl: it would require a recent Linux desktop environment, with applications accessing the camera through pipewire, but the building blocks exist
20:23 DemiMarie: I wonder if Intel licensed the IP from someone and doesn't have the rights to open things.
20:24 pinchartl: (there would then be complains about pipewire not exposing some of the camera controls, that's business as usual, development is quite active there)
20:24 pinchartl: why they don't want to provide information is for them to explain
20:24 pinchartl: my main concern at the moment is that they're not saying what they're willing to open
20:26 DemiMarie: Also the need for per-model tuning (which is expensive if I understand correctly) means that Linux could never be a first-class citizen anyway.
20:27 DemiMarie: Unless I am missing something.
21:21 zf: oh okay, so those options don't do anything unless RADV_DEBUG also includes "shaders", that's a little obscure :-/
22:39 zf: nir_lower_global_vars_to_local() seems to be turning my input varying into a "function_temp", whereupon it's subsequently replaced with "undefined" since it's never written
22:39 zf: that... doesn't seem right? but also seems like it should be breaking pretty much every shader ever, so I must be missing something