00:00 ngcortes: anholt, qq; who's the best contact to ask about the gitlab CI for mesa?
00:05 anholt: probably git log the relevant ci directory?
00:15 ngcortes: anholt, yeah makes sense
01:20 daniels: ngcortes: depends what the question is
01:59 ngcortes: daniels, I was mainly looking to see where the checks are to determine what stages in the pipelines are run (eg. changes in which subdirs of the mesa project trigger testing of specific drivers)
03:06 airlied: mlankhorst: see the tag, don't see the PR
06:04 daniels: ngcortes: it’s in the rules section of each included yml file - try grep ‘rules:’ **/*.yml, and https://docs.gitlab.com/ci/yaml/#rules - which jobs do you think got missed by Marek’s MR?
07:44 mlankhorst: airlied: There now. :-)
07:49 ngcortes: daniels it was bdw, which isn't available to gitlab CI, but we're willing to give some access to the hardware in our internal CI
07:57 daniels: ngcortes: if you’d like to add to the testing fleet, then we’d obviously be very happy to have the help - it would need to look quite different to your internal system though, e.g. no golden kernels, devices rebooted between jobs, etc
08:00 ngcortes: daniels yeah not rebooting between runs would be difficult is the thing. maybe we could ship some to the data center?
08:02 Kayden: I don't think they need the hardware so much as people to keep it maintained and electricity to keep it running
08:03 daniels: ngcortes: if the machines are spare and suitable/sufficient for upstream CI, you could just run them in Intel’s too? there’s no magic involved, it’s all pretty-well documented. Collabora does host all the other Intel boards, but tbh adding 11-year old SDVs to our fleet wouldn’t be my first move …
08:03 daniels: Kayden: yeah, exactly that - the power/network/space does have a cost, but the people to keep the platform alive is a bigger cost really
08:33 mlankhorst: daniels, sima, airlied: The i915 colorop code is also ready to be merged, think we could squeeze that in a topic branch based on drm-misc-next pull request for v6.19 too?
08:56 daniels: mlankhorst: oooh nice
09:25 airlied: mlankhorst: if you can get an MR that is clean
10:18 mlankhorst: airlied: Yeah plan is to base a topic branch on top of the drm-misc-next pull request
11:19 phasta: boah cool, v6.18 is tagged
11:19 phasta:parties hard
11:21 MrCooper: you're a bit late to the party :) it was released on Sunday as usual
11:22 phasta: I'm an upstream dev. Always late 8-)
11:40 ukleinek: phasta: downstream (and worse: vendors) are late. upstream devs notice a release :-)
11:41 phasta: "An upstream developer is never late, Frodo Baggins. Nor is he too soon. He arrives precisely when he means to."
11:42 ukleinek: exactly Phasta Baggins
11:55 sima: mlankhorst, yeah I guess make a topic branch in drm-intel and cherry-pick the minimal set over sounds fine, might as well do all the ones that are ready
20:43 idr: Could someone will to accept responsibility for lavapipe take a look at https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12526/diffs?commit_id=88c9251534e93710fa230326fc3167eede555dc8
20:43 idr: I'd ping zmike, but I think he's still out of the office.
21:06 alyssa: idr: R-b.
21:08 airlied: r-b if it passes CI
21:26 karolherbst: man... promoting CL constant memory to ubo is like super annoying... I wished vtn would be a bit more flexible than it is right now, but before adding tons of complexity there, maybe I just deal with it in rusticl and promote certain chains to ubos... but that means rewriting entire deref chains, but maybe that's fine...
21:26 idr: alyssa, airlied: Thanks!
21:31 cwabbott: gfxstrand: you broke VK_EXT_fragment_density_map with multiview on turnip with your sysval rework
21:33 cwabbott: I have no idea how CTS didn't catch that
21:40 cwabbott: but at least the new custom resolve tests find the issue
21:43 cwabbott: oh right, because I guess it only blows up when there are also input attachments
22:00 cwabbott: or no, it's actually asserting because it explicitly uses gl_ViewID and uses input attachments
22:01 cwabbott: apparently glslang makes gl_ViewID signed when we expect it to be unsigned in lower_sysvals_to_varyings