07:46MrCooper: danvet nanonyme mattst88: I'm also starting to think Xwayland-only releases (independent from general xserver ones, i.e. not dropping Xorg or other DDXen altogether) is the way out of the Xorg quagmire
07:47danvet: MrCooper, does Xwayland load any hw drivers for render accel, or is it glamor only?
07:47MrCooper: mattst88: Xorg seems clearly not in a releasable state, so just throwing out an xserver RC seems like a bad idea
07:48MrCooper: danvet: the latter
07:48nroberts: eric_engestrom, hi, do you get a notification or something if I make a MR against the staging branch? if not here is a manual notification >< https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5731
07:48danvet: ah, so really no problems with driver abi then
07:48MrCooper: it's a monolithic binary, no dynamic loader at all
07:48danvet: I guess the plans from way back to load hw drivers into xwayland never happened
07:48danvet: yeah that should be a lot easier to release at cadence
07:48MrCooper: and BTW it does support modifiers already :)
07:49danvet: MrCooper, the negotiation stuff too?
07:49nroberts: eric_engestrom, hi, do you get a notification or something if I make a MR against the staging branch? if not here is a manual notification >< https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5731
07:49MrCooper: what's the negotiation stuff? :)
07:49danvet: MrCooper, the difference between "has modifiers code" and "has modifiers code enabled by default"
07:50danvet: the set of modifiers that can be done changes dynamically
07:50MrCooper: nroberts: your manual notifications are echoing ;)
07:50danvet: that's why you need atomic TEST_ONLY on the compositor
07:50danvet: and some kind of negotiation/update protocol for clients
07:50danvet: at least if you want to avoid silly copies somewhere
07:50nroberts: MrCooper, oh, sorry, hexchat weirdly disconnected immediately after the first one so I thought it didn’t send
07:50MrCooper: Xwayland is a Wayland client, not a compositor
07:51danvet: yeah, but we still need some kind of modifier negotiation protocol forwarding
07:51danvet: or you end up with copying in Xwayland
07:51danvet: there's essentially 2 sets of (fourcc, modifier) lists
07:51danvet: one is the one GL can composite, which is invariant
07:52MrCooper: it does implement the DRI3 modifier negotiation, but AFAIK the corresponding Wayland protocol is still being discussed
07:52danvet: the other is the one you can direct scanout (or otherwise use more efficiently), which can change every frame
07:52MrCooper: so I guess Xwayland currently gets a static set of modifiers from the compositor
07:58emersion: yes, wayland clients get a list of _supported_ modifiers right now
07:59danvet: unfortunately mutter has a lot of infra work to do still before that can be fixed, but hopefully sway & weston are quicker
07:59emersion: a years-long MR adds support for advertising an ordered list of tranches of _preferred_ modifiers
08:00emersion: the preferred modifiers can be used to kindly ask the client to allocate a buffer with a modifier that can be scanned out
09:27robertfoss: /query tomeu
09:39kusma: karolherbst: I don'
09:40kusma: karolherbst: I don't *think* so, but perhaps you should ask on #tegra instead, as there's more people who know better there?
09:44nanonyme: MrCooper, yeah, maybe so. ajax envisioned in that MR decoupling DRI driver loading from xorg if I understood right but that probably has not been done due to ENOTENOUGHINTEREST
09:45FireBurn: Hi, are there any known issues with kwin at the moment?
09:46MrCooper: nanonyme: that's no blocker for a Xorg release though, other things are, in particular known regressions
09:46FireBurn: Nothing on the screen seems to be updating ubless I move the mouse
09:46FireBurn: And htere's a huge cpu spike
09:47MrCooper: which Mesa Git commit?
09:47nanonyme: MrCooper, right, that's why I was kind of poking around earlier as to whether the broken things are regressions or "still broken" things
09:48MrCooper: there's at least one regression on https://gitlab.freedesktop.org/xorg/xserver/-/milestones/1
09:49nanonyme: Well, then I agree, no point in releasing something that will degrade some workflows
09:51danvet: MrCooper, https://gitlab.freedesktop.org/xorg/xserver/-/issues/542 <- I think this can be closed now?
09:51danvet: we reapplied all the duct-tape at least
09:52danvet: I don't have magic close button powers it seems
09:53danvet: I have no idea which of these would apply to Xwayland too tbh, just spotted that one
09:59MrCooper: looks like it, but I'm afraid I don't care enough
10:30emersion: +1 to Xwayland-only release
11:25tjaalton: would Xwayland-only releases essentially mean continuing with 1.20.x?
12:14karolherbst: maybe somebody here nows. if glsl code has three single component uniforms, do application have tu assume those taking 3 vec4 in the worse case or can they make some assumption about packing?
12:14imirkin: this is in the context of reaching the max allowed uniforms
12:15karolherbst: yeah.. here is the glsl code: https://gist.githubusercontent.com/karolherbst/bd98335b16cf999b59bbd1214a4d0213/raw/f317637fbc6f9a9673cfe8d4e86056e460f4e7e3/gistfile1.txt
12:15karolherbst: (and tgsi and everything)
12:15karolherbst: and we are wondering if this shader uses 4096 or 4097 uniforms in the worse case
12:16karolherbst: wel.. vec4 uniforms
12:16karolherbst: this is about piglit/tests/shaders/glsl-uniform-interstage-limits.c btw
12:17karolherbst: same problem with nir btw
12:36eric_engestrom: nroberts: you can't subscribe to MRs against a particular branch, so no I don't get notifications, but every few days I manually check so I would've seen it eventually :)
12:37eric_engestrom: nroberts: the recommended thing is to just assign backport MRs to the maintainer of that branch, as that does send a notification
12:41kisak: airlied: congrats on pushing llvmpipe forward. Minor question, does the GL 3.0 fake MSAA note in features.txt for llvmpipe outdated?
12:42kisak: (does it still apply or is it outdated)
12:43karolherbst: eric_engestrom: maybe we should label the MRs?
12:43imirkin: afaik he added proper msaa
12:44karolherbst: ohh it was labeled
12:45nroberts: eric_engestrom, ok, thanks for the explanation
12:47eric_engestrom: karolherbst: yeah, it was labeled, and I'm subscribed to that label, so I think I may have accidentally deleted that email (:
12:47eric_engestrom: I need to set up some filtering in my gitlab emails, I get way too many
13:36nroberts: eric_engestrom, it looks like the git fetch failed for the windows build in the pipeline? https://gitlab.freedesktop.org/nroberts/mesa/-/jobs/3461309
13:46MrCooper: eric_engestrom nroberts: the Windows job is currently disabled on master due to this issue
13:54Pe3ucTop: Hi to everyone, question about pinmux , groups and functions . Do pin groups of one function should repeat common pins or function should be defined with multiple groups ?
14:04FireBurn: So I think hte screen not updating when the mouse ins't moving with kwin might be a kernel issue, a plain kernel 5.8-rc3 works fine, but drm-next and agd5f's tree's are giving me issues
14:04FireBurn: Bisecting now
14:05TheRealJohnGalt: Wasn't it fixed with that revert already merged in mesa?
14:06FireBurn: Was that to me?
14:06TheRealJohnGalt: FireBurn: yeah, I thought !5368 was responsible for it. Or at least it was for me.
14:07FireBurn: I'm running the latest master
14:07FireBurn: Or is there still more to be reverted
14:07TheRealJohnGalt: Okay, different issue I guess.
14:17pcercuei: Pe3ucTop: multiple groups
14:38nroberts: anholt__, hi, I’m not sure if I properly understood your comment on the line smoothing MR (5624). do you want to hold off merging the branch until we make a better fix for updating system_values_read?
14:39nroberts: I guess I could make an MR to update system_values_read in nir_load_system_value
14:39nroberts: or maybe just make the lowering pass OR it in directly
15:24FireBurn: So I've gotten as far as 0a19b068acc47d05212f03e494381926dc0381e2 with my bisect
15:24FireBurn: Let me see if that get's picked
15:31FireBurn: airlied: Yeah it's the merge commit I'm haivng issues with
15:32FireBurn: So I'm guessing it's either shared, or soemthing new in i915
15:40FireBurn: The main diff I can see in the non-working config is https://pastebin.com/qFAYxKvy
15:54tomeu: hakzsam: we're getting a bunch of chromebooks in our lava lab with stoney ridge, with the main goal of doing trace testing of radeonsi
15:54hakzsam: tomeu: great news
15:54tomeu: hakzsam: guess we can use the same though for deqp and piglit, and maybe there will be enough bandwidth for testing radv as well?
15:55hakzsam: would be very nice, even if we can run a subset of CTS with radv
16:02MrCooper: tomeu: that'll be awesome!
16:02tomeu: just wanted to check there wasn't any conflicting plans :)
16:03MrCooper: (a bit sad there's still nothing like that from AMD though)
16:04hakzsam: tomeu: not really, we still have no hw at this point but the sw part should be in good shape
16:05tomeu: MrCooper: in a few weeks we should have a bunch of intel chromebooks as well :)
16:06tomeu: this is the first step: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5515
16:13FireBurn: Where do kernel bugs get reported these days, they used to be bugs.f.o, but that moved to gitlab issues but I dont' think the kernel is there yet
16:15imirkin: bugzilla.kernel.org i'd think
16:15bnieuwenhuizen: tue kernel components of bugs.freedesktop.org moved to gitlab as well
16:16bnieuwenhuizen: e.g. https://gitlab.freedesktop.org/drm/amd/-/issues
16:22MrCooper: yeah, bugzilla.kernel.org doesn't work well for graphics stack bugs
16:23bnieuwenhuizen: out of curiosity, what was the issue with bugzilla.kernel.org? Not being able ot move bugs between kernel & userspace?
16:29MrCooper: bnieuwenhuizen: that, plus none of the relevant graphics folks have sufficient privileges in the kernel bugzilla to even e.g. close bugs I think
16:30MrCooper: to be clear, I'm not asking for such privileges :) Just better all round to use GitLab issues
16:31danvet: bnieuwenhuizen, we could add more entries in MAINTAINERS to point people at the right gitlab issues
16:32danvet: there's the B: marker for that, but not many use it yet
16:43TheRealJohnGalt: It seems often that bugs are moved back and forth and seems way better to just use gitlab to me.
17:04mattst88: MrCooper: what makes you say that the xserver isn't in a releasable state?
17:18MrCooper: mattst88: https://gitlab.freedesktop.org/xorg/xserver/-/milestones/1 , in particular the regression on there
17:19MrCooper: to turn that around, what makes you think it is in a releasable state? :)
17:19MrCooper: anyway, even if somebody were to volunteer to manage an xserver release right now, it's probably too late for Fedora 33 already
17:20MrCooper:calling it a day, back tomorrow
17:20mattst88: I had a user recently try out xserver from git, and he discovered one bug, reported it upstream, and got it fixed
17:20mattst88: as far as I'm aware that's the only user of mine I've heard of using xserver from git master
17:21mattst88: so I really have close to no evidence one way or the other
17:21MrCooper: same here, but I'd be kind of surprised if there weren't more regressions
17:23mattst88: that's certainly fair
17:26ajax: if someone wanted to wire up enough vkms in ci to get actual coverage for Xorg...
17:44Lyude: When adding new versions of drm helper callbacks that do the same thing as the old ones but with a drm_modeset_acquire_ctx, should I just add the new version or make the old callback accept a ctx?
17:53karolherbst: ohhh duh.. image lowering is busted :/
18:31anholt__: nroberts: in the absence of fixing the builder, I'd probably just make the pass or it in
18:32anholt__: but no strong feelings, it was r-b regardless
18:35mripard: anholt__: hey, sorry to insist on this one, but could you review patches 1 and 2 of https://patchwork.freedesktop.org/series/78285/
18:35mripard: it shouldn't be very long :)
18:40airlied: kisak: only to softpipe now
19:10nroberts: anholt__, ok, thanks. maybe I will just merge it as is then. that way it will be easier to grep for nir_shader_gather_info if we fix it properly later
19:18tomeu: MrCooper: any suggestions on how to debug these failures? https://gitlab.freedesktop.org/tomeu/mesa/-/jobs/3466757
19:19tomeu: all three piglit jobs fail, and I don't know what could be the cause as the changes to the container image are just adding packages
20:13eric_engestrom: nroberts, MrCooper: commits to disable CIs and things like that never get cc'ed to stable branches so the CI there is always wonky; I usually just ignore when jobs fail for that kind of reasons, but Marge doesn't ignore them :]
20:14eric_engestrom: nroberts: I'm merging your changes manually now, I'll close the MR which means gitlab will say the commits weren't merged but they are if you look at the commit list :)
20:14nroberts: eric_engestrom, ok, great, thanks!