12:27 pq: Does udmabuf uAPI have literally no documentation at all?
12:27 emersion: a classic
12:28 emersion: if you write something i'd review it
12:28 pq: I don't currently have a reason to figure it out myself, so not at this time.
12:29 pq: Was just wondering why a reference to udmabuf was a web link to an email.
12:31 pq: btw. git log -- include/uapi/linux/udmabuf.h is surprisingly unhelpful
12:31 pq: as in, not even the the commit
12:33 pq: if I add --follow, I get lots of commits that have obviously nothing to do with udmabuf
12:37 zmike: alyssa: I'm finding myself wishing you'd added more instr type variants like nir_shader_intrinsics_pass
12:37 zmike: so useful
12:42 glehmann: I thought we have the full set now? tex,alu,intrinsics, even phis
12:43 zmike: oh do we?
12:43 zmike: maybe I missed it
12:43 zmike: huh I did
12:43 zmike: awesome
13:29 alyssa: good talk
14:06 mlankhorst: how should commits committed to wrong trees be fixed?
14:07 dolphin: is it the topmost commit?
14:10 pinchartl: mlankhorst: usually by apologizing and fixing the process/tooling to make sure it same mistake won't happen again
14:14 mlankhorst: dolphin: some drm commits that were committed to drm-intel-gt-next
14:16 mlankhorst: dolphin: top 2 commits in drm-intel-gt-next?
14:17 dolphin: force push without those two commits should be possible
14:18 dolphin: then you'll have to potentially patch up drm-rerere
14:18 mlankhorst: can non-maintainers force push there?
14:19 dolphin: I can do it
14:20 mlankhorst: Yeah go ahead. :)
14:20 dolphin: done, drm-tip seems unharmed too
14:20 mlankhorst: Ideally also a followup commit so the original drm-intel-gt-next cannot be forwarded, but lets monitor
14:22 dolphin: I have to head out right about now, if you don't mind dropping a mail to the mailing list about it?
14:28 dolphin: ah, there is a mail thread on it already, replying there
14:31 mlankhorst: Yeah that's how I found out. :)
15:14 karolherbst: anybody want to review the llvm-22 changes? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39374
15:26 alyssa: karolherbst: a0b
15:26 alyssa: a-b
16:16 karolherbst: thanks!
16:48 Venemo: hey guys, I have a question for anyone working on the drm subsystem, specifically on display related code. what would be a sophisticated way to debug the display related code in the kernel? I am a beginner in this code base and I'm not too familiar with the tools. so I usually end up just adding printk or drm_warn or similar. and if the display hangs or I get black screen, I just log in via ssh from another computer and check the logs
16:48 Venemo: surely there must be a better way to debug that stuff
16:48 Venemo: what do you guys use?
16:59 mlankhorst: about the same
16:59 mlankhorst: sometimes a serial port if I'm being fancy. :)
17:10 CounterPillow: Venemo: you can also use a network console to log to, but since I mostly work on SBC stuff I usually just use serial. Also enabling the right drm dynamic debug levels is helpful, and ftrace can be useful as well
17:11 CounterPillow: I don't ever bother with debuggers
17:13 Venemo: how do you guys set up the serial and/or network debugging? I found some tutorials and tried, but it just didn't work
17:23 CounterPillow: `console` kernel boot param pointing to the serial tty
17:24 CounterPillow: for netconsole, check https://docs.kernel.org/networking/netconsole.html
17:43 pac85: Serial tty can be very slow though so if you print at a high frequency it often can't catch up
17:45 pac85: Though for very high frequency/timing sensitive stuff trace_printk/ftrace in general is better but I can get away with SSH for "once a frame" things
18:35 CounterPillow: that depends very much on your baud rate, at my usual 1.5mbaud I don't have issues in any context where printing itself would be the wrong way to debug something.
18:36 CounterPillow: *wouldn't be
18:58 pac85: I see
19:48 daniels: mripard: did you want to look at https://lore.kernel.org/dri-devel/20260129-dw-hdmi-qp-iframe-v2-0-0157ad05232c@collabora.com/T/#me630c2c686197352e4425edbf20b6e11ade4989c or should I land with my review?
21:25 karolherbst: anybody from the AMD folks who want to look at my nir_opt_offsets changes? I've added support for signed offsets and 64 bit sources and shared2_amd seems like it could benefit from the work there
22:35 Venemo: CounterPillow: I tried that already and it didn't work. it claims that the interface does not exist or something like that. when it in fact exists
22:37 Venemo: CounterPillow: I also tried the serial one, initially it didn't output anything, eventually I got it to 'work' but it was showing messages from systemd and not from the kernel
22:37 Venemo: karolherbst: link?
22:37 karolherbst: ohh I though I posted it.. https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39525
22:37 karolherbst: *thought
22:39 Venemo: looks like you're already getting plenty of reviews but I can take a look
22:39 Venemo: why do you think it has to do with shared2_amd?
22:40 karolherbst: "uint32_t max = INT32_MAX - MAX2(offset0, offset1); /* Avoid negative offsets. */" mostly
22:40 karolherbst: it kinda sounds to me that AMD does support negative offsets, but it's not being used here?
22:40 karolherbst: So I was mostly interested in knowing that whatever I'm doing there would potentially also allow AMD here
22:43 karolherbst: anyway yeah, not lacking review, it was more of a fyi and in case I do something that makes it only more difficult to support in case AMD (or others) also can use negative offsets
23:27 daniels: cwabbott: sorry I forgot about your test - see https://gitlab.freedesktop.org/freedesktop/snippets/-/snippets/7885 for gdb output + https://static.fooishbar.org/tmp/tmp/connor-clip-test-g610.txt for nir dump
23:34 Venemo: karolherbst: good question. I think pendingchaos would know more about that. I think there was a good reason to avoid negative offsets but I don't remember what it was