06:21 tzimmermann: airlied, sima, could you please backmerge -rc5 into drm-next ?
06:39 airlied: tzimmermann: let me take a look
06:39 airlied: tzimmermann: got a reason I can stick in the log?
06:40 tzimmermann: fixes required in drm-misc-next
06:40 tzimmermann: thanks
06:50 airlied: tzimmermann: pushed
06:51 tzimmermann: thanks a lot
06:57 imre: abhinav__: the spec mentions only that the non-transparent mode shall be selected, it doesn't describe the rational for this. Power saving in the commit refers to the fact that in non-transparent mode each lttpr is trained with lttpr specific drive settings, while in transparent mode one drive setting is used for the whole link. The limit on the number of lttprs in transparent mode (as low as 5) is
06:57 imre: described by a Vesa SCR, it's due to link training timeout mandates that couldn't be met with more lttprs than this limit on the link.
09:32 Lynne: zzoon: have you had any luck so far figuring out the av1 issue?
10:24 zzoon: Lynne: I think yes.. going to share patches this week
10:33 Lynne: awesome, thanks
13:09 Curan: I tried opening a MR for Mesa and get a 404 (after logging into the FDO GitLab instance) for the MR create URL. Doesn't matter if I click the button in the branch or if I use the URL I got in the shell after pushing. Is some cache broken after the move to Hetzner or do I need new rights? Before I was able to create MRs.
13:10 Curan: branch in question would be https://gitlab.freedesktop.org/curan/mesa/-/commits/curan/fix/ftbfs-llvm21-targetoptions-protected (fixing #13079)
13:26 eric_engestrom: Curan: this is something for bentiss on #freedesktop; could you post that message there?
13:26 Curan: Sure, thanks for the pointer
13:27 eric_engestrom: but also, iirc he was thinking of (mostly) getting rid of the cache since gitlab cannot be trusted (incorrect caching headers from gitlab resulting in all of these issues), so maybe it will all be gone soone anyway
13:29 Curan: seems reasonable then, even though it is kind of annoying to have no proper cache at all; I guess one key for the cache could be the login state? Ah well, he'll know better
13:41 eric_engestrom: it's already keyed on the login session
13:42 eric_engestrom: but the main problem is gitlab telling the cache to store temporary result (like the 404 on a just-created branch), or no-cache on something that should be cached
13:43 eric_engestrom: hopefully one the AI attacks get big enough that gitlab.com can't just throw more money/hardware to keep things usable, they'll have to start using caching tools and they'll start caring about fixing their cache headers 🙃
13:43 eric_engestrom: *hopefully once
13:46 eric_engestrom:is bitter and will just walk away from this topic now
14:51 eric_engestrom: I'm writing the release note for tomorrow's 25.1.0, and I'm wondering if there are anything "big news" worth mentioning, other than asahi's uapi being merged, allowing the driver to now be used in mainline mesa, removing the need for custom distro builds
14:51 eric_engestrom: keeping in mind that the main audience for these is distro packagers, not end users
14:54 eric_engestrom: I should have asked this earlier, but you have about 24h to let me know if there's something else ^^
14:54 daniels: support for Mali G720/G925
14:55 daniels: YCbCr support in panvk for v10+ GPUs (Gxxx)
14:56 daniels: about a billion new extensions and feature bits as well as significant performance improvements
15:13 eric_engestrom: the new_features.txt file is always in the release email, so anything mentioned there doesn't need to be repeated
15:15 eric_engestrom:needs to put in place a structure for devs to write release notes in a higher level than new_features.txt, but hasn't done it yet
15:15 eric_engestrom: "higher level" as in, "support for Mali G720/G925" kind of thing
15:16 eric_engestrom: instead of "VK_EXT_foo on gen37"
15:16 zmike: seems like extension support could be automated by just diffing features.txt between branches
15:17 zmike: which would clean up the majority of new_features.txt
15:17 eric_engestrom: true
15:18 eric_engestrom: but then I'm also working on getting rid of features.txt ^^
15:18 eric_engestrom: (well, for vulkan)
15:18 eric_engestrom:needs to get back to that at some point
17:08 jenatali: I'd asked about this a while ago in the abstract, but wanted to bring it up now that it's more concrete. We've got a new video frontend we'd like to upstream and would welcome any feedback: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34843
17:08 jenatali: Also, if there's no objections, I was thinking I'd go ahead and create a 'mediafoundation' label for it
17:10 zmike: pls don't merge before the framebuffer/surface thing lands
17:10 zmike: I will die if I have to do more merge conflicts/rewrites
17:10 jenatali: Heh, yeah that's fair
17:24 abhinav__: imre thanks so much for the explanation. just one follow up question, even for the recommendation that non-transparent mode needs to be selected, isnt that only for 128b/132b encoding/UHBR rates? For 8b/10b encoding, I am not seeing a recommendation as such
18:56 eric_engestrom: jenatali: when you create a label, add corresponding lines in `.mr-label-maker.yml` :)
18:57 eric_engestrom: *remember to add
19:00 jenatali: eric_engestrom: Yep, will do
19:31 alyssa: looking into what we need for nightly Mesa copr builds
19:31 alyssa: I think there's a couple of individually maintained coprs but nothing that seems to have community buy-in the way that e.g. AUR mesa-git does?
19:32 alyssa: it's come up that the "right" way for Fedora might be Packit, which requires adding a little .packit.yaml file (and possibly a .spec) into the upstream mesa src tree .. is that going to be acceptable?
19:33 alyssa: obviously I can do whatever for an asahi-specific copr but it would be cool to get this solved upstream for everyone instead
19:33 alyssa: (and now that the uapi is merged I don't strictly *need* to take nightlies out of a downstream)
19:34 alyssa: It feels a little icky to have distro-specific packaging stuff in the upstream tarball, but.. we already have .gitlab-ci/, that boat's sailed
19:37 alyssa: systemd seems to have the .packit.yml upstream but not the spec file which might be reasonable for mesa too? https://github.com/systemd/systemd/blob/main/.packit.yml
19:39 alyssa: (I suppose we could teach mesa ci to produce rpm's. I am pretty sure that's the worst of the worlds option here, though)
19:40 alyssa: (Although maybe actually packit+gitlab-ci makes sense https://packit.dev/docs/guide#gitlab-pipelines ? IDK, I'm new to all this.)
20:25 eric_engestrom: alyssa: I actually started looking into getting our ci to output distro packages a couple of years ago (https://gitlab.freedesktop.org/eric/mesa/-/commits/ci-fedora-rpm)
20:26 eric_engestrom: the idea was to have an easy way to get users to test MRs
20:30 eric_engestrom: having that in nightly pushes us further towards becoming distro packagers, which I'm not sure we want to do, as users expectations risk rising significantly... but then again, if it's already done by some third party, it's not worse to do it ourselves
20:36 alyssa: eric_engestrom: yeah..
20:49 alyssa: zmike: ..that's an ack, right? :P
22:30 abhinav__: imre Hi, sorry but one more question, can you pls share the SCR version which has this information "limit on the number of lttprs in transparent mode (as low as 5)"
22:59 Company: alyssa, eric_engestrom: I think what you want is to find communities that are interested in living on the edge and convince them to ship Mesa nightly
23:00 Company: I think gnome-nightly works nicely for GTK
23:01 Company: and in general, flatpaks solve the issue of being able to run nightly stuff without screwing up your system
23:01 Company: though you'd probably not want gnome-nightly, but steam-nightly and things like that I suppose?
23:02 Company: flatpaks also have the benefit of working on all distros unlike copr or aur stuff