00:04jekstrand: kisak: Is that what's giving Marge heartburn?
00:07kisak: looks like it, yes
00:11anholt_:is stepping away, but someone should push the disable of the windows runner in that case
00:32bl4ckb0ne: is there somebody from the montreal collabora office here?
00:35shadeslayer: bl4ckb0ne: AFAIK no one's at the office though
00:36bl4ckb0ne: yeah, i just want to speak to somebody from the montreal area who works at collabora
05:28daniels: kisak, anholt: runner is back
05:29daniels: bl4ckb0ne: most of the Montréal people are GStreamer, you could try ndufresne or ocrete but they aren't on this channel
07:16anarsoul|2: imirkin: hi, can you explain what is "different sizes for fb color/zs attachments" in PIPE_CAP_MIXED_FRAMEBUFFER_SIZES?
07:20MrCooper: not all colour/depth/stencil buffers having the same width/height
07:20anarsoul|2: I see, thanks
07:21MrCooper: it's one notable difference in GL_ARB_framebuffer_object vs _EXT_
07:22anarsoul|2: i.e. no luck for gles2 gpus :)
08:06airlied: jekstrand: when you ran 1.2.2 did you see fails for opspeconstantop tests?
08:38MrCooper: pq: fbcon doesn't even reliably restore the gamma LUT when switching to it...
09:36pq: MrCooper, >_<
09:37emersion: pq: fwiw i completely agree with your last e-mail on the topic
09:40pq: emersion, thanks :-)
09:41pq: it seems the current kernel policy is: your initial KMS state is undefined. Good luck!
09:43MrCooper: what could go wrong?
11:03kennylevinsen: Hmm. When/how should one ping patches? Got this silly little thing that I don't know what to do with: https://patchwork.kernel.org/patch/11485341/.
11:05ickle: what are they doing to generate events then?
11:06ickle: they are vblank events, it's listening to the fd it gives out to a compositor
11:07kennylevinsen: is that for me?
11:07ickle: it's your patch
11:07emersion: ickle: systemd is not interested in vblank events
11:08emersion: only interested in EPOLLERR|EPOLLHUP
11:08emersion: they don't ask for events at all
11:08ickle: that is clear, but what is doing listening to vblank events
11:08kennylevinsen: systemd only holds the fd for logind, and is only polling to know whether the fd is dead.
11:08emersion: ickle: ah, i see what you mean
11:09emersion: kennylevinsen: these codepaths shouldn't be hit for systemd
11:09ickle: not that the patch doesn't sound sensible, just curious
11:09emersion: kennylevinsen: drm_send_event_locked shouldn't be called for systemd FDs, because systemd doesn't ask for events
11:09ickle: because I'm getting shivers if systemd is keeping the master fd around
11:10pq: systemd's file description is the same as the compositor's file description, is it not?
11:10kennylevinsen: the fd that is given to the compositor by logind is the same as it sends to systemd for "safe-keeping"
11:10emersion: dup'ed and sent to the compositor?
11:10emersion: yeah, that makes sense
11:12pq: dup and sendmsg/recvmsg only create new file descriptors, not new file descriptions. So I guess systemd gets everything the compositor asks for.
11:12kennylevinsen: Yeah, that's also my assumption here. The patch certainly has the intended effect, as systemd was indeed waking up for drm activity in a perf trace, and this removes it.
11:12emersion: kennylevinsen: you could ping a DRM maintainer like Daniel Vetter
11:12pq: I guess systemd/logind has to keep the fd, so that it can force DRM drop master on it?
11:12kennylevinsen: (With my laptop usually clocking 800MHz, I tend to notice those things)
11:13kennylevinsen: systemd's own holding and polling is only to give it back to logind if it is restarted. :/
11:13kennylevinsen: logind itself doesn't poll the fds at all
11:14pq: but does logind need it for forcing drop-master, or?
11:15kennylevinsen: Yeah, it's used for dropmaster/setmaster
11:17emersion: kennylevinsen: in general it doesn't really work to just send patches to dri-devel without CC'ing some people. finding maintainers and using git-blame to know who touched the file recently can help.
11:18kennylevinsen: I CC'ed 3 drm-misc maintainers based on the get maintainer script suggestions, but I suppose it just fell over the event horizon of their inboxes
11:19emersion: ahah, ok, patchwork doesn't explicitely show this info
11:19emersion: often people add Cc tags to the commit message directly
11:20kennylevinsen: Yeah, being only my second kernel patch, I'm not quite sure of the processes yet.
11:20kennylevinsen: (the first one being, surprise surprise, the exact same thing in evdev. systemd polls all the things.)
11:23kennylevinsen: should I just reply with a ping and add daniel vetter on the CC?
12:50jekstrand: airlied: Yup. https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4675
13:10MrCooper: emersion: it's actually mailman which removes some addresses from Cc: of the list posts it sends out, based on their subscription preferences
13:52sravn: danvet, tzimmermann, mripard: kennylevinsen pings abouts https://patchwork.kernel.org/patch/11485341/
13:53sravn: kennylevinsen: I just pinged a few ppl for you here
13:53kennylevinsen: Ah, thanks a lot. :)
14:03danvet: kennylevinsen, hm can you pls resubmit with intel-gfx cc'ed? there's a CI bot there that would be good for testing this
14:03danvet: in addition to dri-devel mailing lists
14:04danvet: sumits, you're going to apply my compat fix for dma-buf SET_NAME ioctl, right?
14:05danvet:kinda super distracted with too much stuff
14:05kennylevinsen: Sure thing. Should I mark it as resubmitted somehow, or is it fine as is?
14:43bl4ckb0ne: thanks daniels
14:57sravn: kennylevinsen: Based on the irc logs you can improve the changelog. Do so and mark it v2 when you send it again
14:59sravn: danvet: Maybe not the best time to annoy you with small more or less silly feedback on the drmm patches. But lets see if I spot something. Expect to finally process them today
15:03danvet: sravn, bring it on, I dont think I'll get around to applying this week
15:03danvet: kennylevinsen, what sravn said sounds good
16:15sumits: danvet, yes, I am, sometime tonight, or tomorrow?
18:13sravn: danvet: A few things to look at when you get out of the maze of distractions you are entangled in. Everything touching component.h I steered away from - too much headace already..
18:13Lyude: seanpaul: btw - just got the patch on the mailing list to remove the second mst tx slot entirely
18:18Lyude: at some point (probably when I finally get around to finishing up the rad printf stuff) I might also change how we dump sideband txmsgs to reflect this, since the only reason we use such a large format for them in dmesg is because I expected us to eventually be making interleaved replies as a default
18:18Lyude: doesn't make as much sense now that we've only got one tx slot and one mstb we're communicating with at a time
18:22seanpaul: Lyude: oh neat, did a quick scan and that lines up with what i was thinking. i'll do a deeper review later this afternoon, thanks!
18:45danvet: sravn, hm where did I touch component.h?
19:04sravn: danvet: s/component.h/component framework/ - in other words komeda and armada. I know component framework try to address dependencies somehow but so far I have not wrapped my head araound it
19:07danvet: sravn, yeah, that's kinda why I'd like to get bridge drivers away from component.h completely
19:08Lyude: seanpaul: btw - sent out another fix, could use a review of that while you're at it if you've got the time
19:13airlied: jekstrand: did u see my q last night?
19:13jekstrand: airlied: Did you see my a this morning?
19:14jekstrand: airlied: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4675
19:14airlied: nope i musta failed on highlight search
19:14jekstrand: merged already, even.
19:15airlied: i had seen the mr but hadnt.linked.it to fixing those tests
19:15airlied: guess i gotta rebase it all
19:15jekstrand: Yup, it fixes about 6 or 8 for us
19:15airlied: does anyone on hw drivers ever see random malloc corruption with cts?
19:16airlied: valgrind never finds it even helgrind but its probs an llvmpipe thread issue
19:17alyssa: any easy way to test int8 without getting clover going?
19:20airlied: get vulkan going
19:20alyssa: airlied: >:D
19:20HdkR: Vulkan you say
19:21alyssa: airlied: I assume clover would be far easier than vulkan
19:21alyssa: otoh ... I don't need LLVM for vulkan do I? >:
19:23alyssa: Joking aside - I wonder if I can jury rig spirv_to_nir into the standalone compiler?
19:25alyssa: ir3 does it, good enough for me <3
19:25airlied: yeah that migbt be easier
19:25alyssa: airlied: but if you do want to write a Vulkan driver for panfrost, we accept merge requests ;D
19:31bnieuwenhuizen: airlied: I think we sometimes see some on a vulkan CTS run we do for conformance. the parallel CTS runner we use most of the time restarts the process so often we don't notice though
19:32bnieuwenhuizen: (with RADV)
19:33bnieuwenhuizen: like I think the 5th shard (out of 8 shards when doing the sharded conformance submission) failed about 1 out of 5 runs or something like that
19:36alyssa: Oh, GL_EXT_shader_explicit_arithmetic_types_int8 exissts, this is horrifying, I love it
19:37imirkin: NV_gpu_shader5 has int8 iirc
19:37imirkin: (and a lot of other things)
19:40imirkin: that explicit arithmetic types ext is a nice find
19:41imirkin: it's still preliminary it seems though - no ext number
21:00jekstrand: airlied: Not often. It's actually pretty good these days.
21:01jekstrand: It used to be that GLSLang would barf all over everywhere when you ran with valgrind.
21:22bnieuwenhuizen: hakzsam: I think radv-fossils has a missing dependency: https://gitlab.freedesktop.org/JoshuaAshton/mesa/-/jobs/2437339 (missing artifacts seem logical as the x86_build image failed to build and hence none of the meson jobs have run yet)