00:04 jekstrand: kisak: Is that what's giving Marge heartburn?
00:07 kisak: looks like it, yes
00:11 anholt_:is stepping away, but someone should push the disable of the windows runner in that case
00:32 bl4ckb0ne: is there somebody from the montreal collabora office here?
00:35 shadeslayer: bl4ckb0ne: AFAIK no one's at the office though
00:36 bl4ckb0ne: yeah, i just want to speak to somebody from the montreal area who works at collabora
05:28 daniels: kisak, anholt: runner is back
05:29 daniels: bl4ckb0ne: most of the Montréal people are GStreamer, you could try ndufresne or ocrete but they aren't on this channel
07:16 anarsoul|2: imirkin: hi, can you explain what is "different sizes for fb color/zs attachments" in PIPE_CAP_MIXED_FRAMEBUFFER_SIZES?
07:20 MrCooper: not all colour/depth/stencil buffers having the same width/height
07:20 anarsoul|2: I see, thanks
07:21 MrCooper: it's one notable difference in GL_ARB_framebuffer_object vs _EXT_
07:22 anarsoul|2: i.e. no luck for gles2 gpus :)
08:06 airlied: jekstrand: when you ran 1.2.2 did you see fails for opspeconstantop tests?
08:06 airlied: shiftrightarithmetic_i64*
08:06 airlied: ?
08:38 MrCooper: pq: fbcon doesn't even reliably restore the gamma LUT when switching to it...
09:07 emersion: :S
09:36 pq: MrCooper, >_<
09:37 emersion: pq: fwiw i completely agree with your last e-mail on the topic
09:40 pq: emersion, thanks :-)
09:41 pq: it seems the current kernel policy is: your initial KMS state is undefined. Good luck!
09:42 emersion: indeed
09:43 MrCooper: what could go wrong?
11:03 kennylevinsen: 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:05 ickle: what are they doing to generate events then?
11:06 ickle: they are vblank events, it's listening to the fd it gives out to a compositor
11:07 ickle: ?
11:07 kennylevinsen: is that for me?
11:07 ickle: it's your patch
11:07 emersion: ickle: systemd is not interested in vblank events
11:08 emersion: only interested in EPOLLERR|EPOLLHUP
11:08 emersion: they don't ask for events at all
11:08 ickle: that is clear, but what is doing listening to vblank events
11:08 kennylevinsen: systemd only holds the fd for logind, and is only polling to know whether the fd is dead.
11:08 emersion: ickle: ah, i see what you mean
11:09 emersion: kennylevinsen: these codepaths shouldn't be hit for systemd
11:09 ickle: not that the patch doesn't sound sensible, just curious
11:09 emersion: kennylevinsen: drm_send_event_locked shouldn't be called for systemd FDs, because systemd doesn't ask for events
11:09 ickle: because I'm getting shivers if systemd is keeping the master fd around
11:10 pq: systemd's file description is the same as the compositor's file description, is it not?
11:10 emersion: hmmm
11:10 kennylevinsen: the fd that is given to the compositor by logind is the same as it sends to systemd for "safe-keeping"
11:10 emersion: dup'ed and sent to the compositor?
11:10 emersion: yeah, that makes sense
11:12 pq: dup and sendmsg/recvmsg only create new file descriptors, not new file descriptions. So I guess systemd gets everything the compositor asks for.
11:12 kennylevinsen: 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:12 emersion: kennylevinsen: you could ping a DRM maintainer like Daniel Vetter
11:12 pq: I guess systemd/logind has to keep the fd, so that it can force DRM drop master on it?
11:12 kennylevinsen: (With my laptop usually clocking 800MHz, I tend to notice those things)
11:13 kennylevinsen: systemd's own holding and polling is only to give it back to logind if it is restarted. :/
11:13 kennylevinsen: logind itself doesn't poll the fds at all
11:14 pq: aha
11:14 pq: but does logind need it for forcing drop-master, or?
11:15 kennylevinsen: Yeah, it's used for dropmaster/setmaster
11:16 pq: cool
11:17 emersion: 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:18 kennylevinsen: 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:19 emersion: ahah, ok, patchwork doesn't explicitely show this info
11:19 emersion: often people add Cc tags to the commit message directly
11:20 kennylevinsen: Yeah, being only my second kernel patch, I'm not quite sure of the processes yet.
11:20 kennylevinsen: (the first one being, surprise surprise, the exact same thing in evdev. systemd polls all the things.)
11:23 kennylevinsen: should I just reply with a ping and add daniel vetter on the CC?
12:50 jekstrand: airlied: Yup. https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4675
13:10 MrCooper: emersion: it's actually mailman which removes some addresses from Cc: of the list posts it sends out, based on their subscription preferences
13:52 sravn: danvet, tzimmermann, mripard: kennylevinsen pings abouts https://patchwork.kernel.org/patch/11485341/
13:53 sravn: kennylevinsen: I just pinged a few ppl for you here
13:53 kennylevinsen: Ah, thanks a lot. :)
14:03 danvet: 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:03 danvet: in addition to dri-devel mailing lists
14:04 danvet: sumits, you're going to apply my compat fix for dma-buf SET_NAME ioctl, right?
14:05 danvet:kinda super distracted with too much stuff
14:05 kennylevinsen: Sure thing. Should I mark it as resubmitted somehow, or is it fine as is?
14:43 bl4ckb0ne: thanks daniels
14:57 sravn: kennylevinsen: Based on the irc logs you can improve the changelog. Do so and mark it v2 when you send it again
14:59 sravn: 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:03 danvet: sravn, bring it on, I dont think I'll get around to applying this week
15:03 danvet: kennylevinsen, what sravn said sounds good
16:15 sumits: danvet, yes, I am, sometime tonight, or tomorrow?
18:13 sravn: 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:13 Lyude: seanpaul: btw - just got the patch on the mailing list to remove the second mst tx slot entirely
18:18 Lyude: 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:18 Lyude: 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:22 seanpaul: 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:45 danvet: sravn, hm where did I touch component.h?
19:04 sravn: 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:07 danvet: sravn, yeah, that's kinda why I'd like to get bridge drivers away from component.h completely
19:08 Lyude: seanpaul: btw - sent out another fix, could use a review of that while you're at it if you've got the time
19:13 airlied: jekstrand: did u see my q last night?
19:13 jekstrand: airlied: Did you see my a this morning?
19:14 jekstrand: airlied: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4675
19:14 airlied: nope i musta failed on highlight search
19:14 jekstrand: merged already, even.
19:15 airlied: i had seen the mr but hadnt.linked.it to fixing those tests
19:15 airlied: guess i gotta rebase it all
19:15 jekstrand: Yup, it fixes about 6 or 8 for us
19:15 airlied: does anyone on hw drivers ever see random malloc corruption with cts?
19:16 airlied: valgrind never finds it even helgrind but its probs an llvmpipe thread issue
19:17 alyssa: any easy way to test int8 without getting clover going?
19:20 airlied: get vulkan going
19:20 airlied: :-p
19:20 alyssa: airlied: >:D
19:20 HdkR: Vulkan you say
19:21 alyssa: airlied: I assume clover would be far easier than vulkan
19:21 alyssa: otoh ... I don't need LLVM for vulkan do I? >:
19:23 alyssa: Joking aside - I wonder if I can jury rig spirv_to_nir into the standalone compiler?
19:25 alyssa: ir3 does it, good enough for me <3
19:25 airlied: yeah that migbt be easier
19:25 alyssa: airlied: but if you do want to write a Vulkan driver for panfrost, we accept merge requests ;D
19:31 bnieuwenhuizen: 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:32 bnieuwenhuizen: (with RADV)
19:33 bnieuwenhuizen: 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:36 alyssa: Oh, GL_EXT_shader_explicit_arithmetic_types_int8 exissts, this is horrifying, I love it
19:37 imirkin: NV_gpu_shader5 has int8 iirc
19:37 imirkin: (and a lot of other things)
19:40 imirkin: that explicit arithmetic types ext is a nice find
19:41 imirkin: it's still preliminary it seems though - no ext number
21:00 jekstrand: airlied: Not often. It's actually pretty good these days.
21:01 jekstrand: It used to be that GLSLang would barf all over everywhere when you ran with valgrind.
21:22 bnieuwenhuizen: 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)