01:13 mareko: how do I get rid of false positive in the CI linting job?
01:13 soreau: rm -rf CI
01:13 mareko: other than that
01:13 soreau: xD
01:14 mareko: it's not an unreasonable option
01:14 soreau: hehe
01:15 mareko: it doesn't seem like piglit should have codespell in the CI, or anything else
01:33 mareko: I meant the linting job, not the CI
08:20 Lynne: any plans to support VK_EXT_memory_decompress?
08:23 Lynne: I could probably write shaders to run it, since it looks like I'll be writing a fast CPU compression library
09:16 glehmann: the shader already exists: https://github.com/HansKristian-Work/vkd3d-proton/blob/master/libs/vkd3d/shaders/cs_gdeflate.comp
10:31 daniels: mareko: not sure if you figured it out already, but piglit/.gitlab-ci.yml hsa an exclusion list - if you grep for 'codespell', the -L in that line is a list of words to ignore
14:48 silurian_invader: does vblank include the vertical front porch?
16:44 silurian_invader: and what *is* a vblank event?
16:45 silurian_invader: if they are for userspace, why is drm_crtc_arm_vblank_event so concerned about hardware state?
16:48 mlankhorst: It's for the kernel as well, to know when the update completes and the old fb can be unpinned
16:49 mlankhorst: So part of it is exactly that. vblank signaling to the kernel that the old state can be cleaned up
16:51 silurian_invader: ok, but there's a long explanation about how you need to update hardware state during the same vblank you send the event in
16:51 silurian_invader: added in commit 61802130d85f ("drm: Document caveats around atomic event handling")
16:51 silurian_invader: and I don't think that matters for disabling?
16:52 mlankhorst: Some hardware will not handle being disabled correctly while actively scanning out
16:52 silurian_invader: so does crtc_atomic_disable get called when the event is sent?
16:56 mlankhorst: If a modeset happens, the event may be sent out not after disable, but after re-enable completes.
16:58 silurian_invader: ok, so for some background, I'm working on a crtc that has a vblank interrupt, can timestamp the vblank, and does not have a "go" bit
16:59 mlankhorst: It's not required, vblanks are enabled like usual, so as long as you handle vblank interrupts it works
16:59 silurian_invader: it currently calls drm_crtc_arm_vblank_event in its atomic_flush
16:59 silurian_invader: should it be doing that?
17:01 mlankhorst: seems so if I take vkms as reference
17:02 silurian_invader: well, vkms effectively has a "go" bit with composer_state
17:03 silurian_invader: and it's also doing a lot more work in its vblank interrupt; my crtc just calls drm_crtc_handle_vblank
17:03 silurian_invader: (and it also doesn't have a "real" vblank to manage)
17:04 mlankhorst: I believe that is enough
17:06 silurian_invader: but is it too much? drm_crtc_arm_vblank_event seems pretty clear that you're not supposed to use it unless you can actually do an atomic commit
17:06 silurian_invader: so I'm wondering why all these drivers are calling it
17:08 silurian_invader: I guess I don't really understand what atomic_flush is supposed to do
17:08 silurian_invader: the documentation talks about what implementations *can* do, but it doesn'
17:08 silurian_invader: t actually say what the purpose is
17:09 mlankhorst: Allow unprepare_fb() to only run after no longer scanning out, and optionally notify userspace that atomic commit completed
17:11 silurian_invader: so by the time atomic_flush happens, the hardware has already been reprogrammed, and we are just waiting for it to be committed?
17:12 silurian_invader: in which case, if the hardware doesn't have a "go" bit and we need to wait for a vblank before beginning programming, then that should happen in some other function (atomic_begin)?
17:32 silurian_invader: and what should I do if the hardware doesn't support timestamps?
17:32 silurian_invader: the hardware does, but it needs a devicetree update so new kernel/old dt won't be able to timestamp the vblank
18:21 austriancoder: alyssa: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38169#note_3173417
18:33 alyssa: austriancoder: Uh oh
18:33 alyssa: Someone should probably tell an Intel employee..
18:34 alyssa: Oh wait
18:34 alyssa: looking
18:35 alyssa: austriancoder: Works for me..
18:35 alyssa: on LNL
18:37 alyssa: austriancoder: I wonder if alignment is zero..
18:37 alyssa: this would be a bug in anv I think
18:38 alyssa: Hmm no that would've blown up before too
18:40 alyssa: I'm not seeing the bug
18:40 mlankhorst: silurian_invader: Yeah I guess you could program in the vblank irq, then send out updates? i915/display does the opposite and programs outside the vblank window
18:42 alyssa: Oh, I see
18:42 alyssa: util_is_aligned (n=0, a=0)
18:42 alyssa: Cursed.
18:42 alyssa: Well.. 0 isn't a power-of-two so I'd say this was a preexisting bug in anv
18:43 alyssa: austriancoder: I think you can write the patch from here. I can't repro so
18:44 alyssa: Or maybe we can consider 0 to be 0 aligned
18:44 alyssa: that seems.. reasonable
18:44 mlankhorst: Anything is a multiple of 0
18:44 alyssa: Yeah.. Just need to update an assert & a comment
18:46 alyssa: patch coming
18:49 alyssa: austriancoder: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38191
18:52 alyssa: btw i hadn't used ci_run_monitor in a few years, UI is a lot nicer now. thanks :-)
18:52 alyssa: (@sergi maybe?)
18:55 alyssa: the links are a *really* nice touch
18:58 daniels: david & eric did a bunch on that one
19:01 alyssa: Thanks both :)
19:01 alyssa: also TIL the existence of OSC 8
19:10 zmike: alright everyone, see you next year!
19:12 HdkR: But who is going to take up the position of resident shit poster in their two month leave?!
19:21 alyssa: halloween mike be like
19:22 alyssa: HdkR: hiiiiiiiii
19:22 alyssa: uwu
19:22 HdkR: alyssa: It's a big task, are you up to it?
19:23 alyssa: probably not
19:24 HdkR: Me either, I don't think I can be as efficient.
19:36 alyssa: shitposting will continue until morale improves
19:37 HdkR: :blobsweat:
19:40 alyssa: 7778
19:40 alyssa: uhh
19:40 alyssa: hy i my kyo no okkin
21:32 austriancoder: alyssa: thanks
23:36 mareko: daniels: yeah I noticed that, though it's probably best to keep only jobs that are unanimously helpful
23:36 mareko: if there is any uncertainty regarding its usefulness, it probably shouldn't be there