00:57 lumag_: @lucaceresoli: I am attending, but no promise of me being able to take a look, sorry
00:58 lumag_: mupuf, sima: we are very much interested in drm CI, be it the current one or some new form of the same idea.
06:23 tzimmermann: mupuf, sima, mripard, sorry i'm out of the loop. whith the single-tree setup, what will be the workflow then? everyone merged directly into drm-next, drm-fixes, etc? or will drm-misc absorb all per-driver trees and patches will flow from there into drm-next, drm-fixes?
06:49 airlied: tzimmermann: I think misc absorb
06:53 tzimmermann: that makes me worry about the size of the weekly PRs
06:55 airlied: tzimmermann: yeah me too which I think is a reason not to do it
06:55 airlied: I think summaries would get very large to write
06:59 tzimmermann: indeed. we used to have ~250 changes in the large first PR after -rc1. it's a bit lower now (150-200) but still large. adding the big driver trees could easily get us over 400 commits on the -rc1 change. all the other weekly PRs will scale accordingly. i honestly do not look forward to this
07:00 lucaceresoli: lumag_: ack! Glad to see yop there too :)
07:00 lucaceresoli: s/yop/you/
07:04 airlied: tzimmermann: I honestly don't think we should be going that direction either, tree sizes are just about manageable at the moment
07:06 tzimmermann: same here
07:25 MrCooper: airlied: not sure what exactly you mean by "giving MR/CI privs to everyone"; FWIW, merging MRs to a branch can be limited to the same users which can already push to it directly
07:45 sima: tzimmermann, airlied I guess what we could change (might make sense anyway) is to keep drm.git open all the time like the lower trees and maybe do something with per-release branch like agd5f does instead of what we have now with just two branches
07:45 sima: so that there's no big -rc1 pr when we reopen
07:45 sima: but also a bit orthogonal
07:46 sima: or maybe a drm-next-mergewindow or something like that
07:47 sima: I think intel folks do something like that nowadays by just tagging intermediate stages instead of having to summarize over a month
07:48 tzimmermann: sima, if this is mostly about CI, why not run that on drm-tip?
07:49 sima: I think something like that would also be the only way to make a megatree work for summaries, maybe something like maintianer-on-duty makes a prelim tag, area experts type up summaries for everything, then maintainer-on-duty integrates it all into one big thing
07:49 sima: tzimmermann, we want both, since sometimes drm-tip hides issues in branches due to everything being merged together
07:49 sima: which unnecessarily makes bisecting less useful
07:50 sima: this holds even more so when you track xfails and all that, there you really want to update those together with adding patches
07:50 sima: or doing merges
07:50 sima: it's why people are pushing to have at least some of the drm-ci stuff in the upstream tree (specifically those xfail lists)
07:52 tzimmermann: sima, most of us maintainers have other duties as well. our workflow should remain simple as well.
07:53 sima: yeah, I think that was in the past some of the reasons for not making drm-misc substantially bigger
07:54 sima: there's a bit a sweet spot between "tree too small, not enough maintainer volunteer candidates to run it"
07:54 tzimmermann: i mean, i'm not thrilled by ideas about additional tags and branches to juggle with
07:54 sima: and "tree too big, no one wants to do the maintainer job because it's too much"
07:55 sima: tzimmermann, I think if you just cut one release every 2-3 months just editing the summary in a file in-tree would work
07:55 sima: but since we have regular pr that's kinda awkward
07:57 tzimmermann: not sure what you mean
07:58 tzimmermann: i also don't think that making PRs is parallalizable
08:00 tzimmermann: as in "having multiple people prepare the PR". that just waters down responsibility
08:17 sima: tzimmermann, if we'd only do one big release like mesa then the coordination pain of collecting summaries could be bearable
08:17 sima: trying to pull that off weekly does indeed feel like too complicated to work
08:34 tzimmermann: the big-release scenario seems to re-create our current drm-next
08:36 tzimmermann: we currently coordinate among the 3 of us in drm-misc, which works quite well. i don't see this working out with a dozen people or more.
08:36 tzimmermann: the finger pointing starts as soons as soemone doesn't show up for duty
08:38 pq: The workflow discussion reminded me that I haven't tried https://gitlab.com/bichon-project/bichon again for several years. Looks like its development has almost died, too. It's a terminal-based program for (off-line) Gitlab MR reviewing.
08:43 tzimmermann: "dim status" says: "Fetching drm... git@ssh.gitlab.freedesktop.org: Permission denied (publickey)" it worked ~1hr ago
08:45 phasta: is gitlab.freedesktop.org down for you guys, too?
08:46 tzimmermann: phasta, yes
08:47 jani: airlied: sima: writing pull request changelogs has been one thing I've considered using LLMs for ;)
08:49 jani: it's the worst when you're running late with the PR already, you've accumulated more patches than you'd like in one go, deadline's looming, you realize you need to nag at people for writing poor commit messages that don't translate to changelogs at all (need to go read code to make sense of the changes), etc.
08:49 jani: and then you *never* get *any* feedback from *anyone* no matter how good or bad or mediocre the changelog is
08:50 phasta: jani: you mean feedback on IRC, or people don't answer DMs when you ask them about what a patch does?
08:51 jani: phasta: no, I mean the actual PR changelog you come up with
08:51 jani: airlied: I see linus nag at you for PR mails, but I don't see you give any feedback what would help you in the job, or what makes your job hard
08:53 phasta: jani: I suspect that is because few people read dri-devel carefully. You could +Cc the contributors in the PR mail, but that would be a huge list, of course. Nevertheless, I suspect far more people would answer then
08:53 jani: phasta: as to getting clarification for commit messages, I usually just don't have the time to wait for people to respond to me. I turn the poor commit message into a changelog item myself, and reply on the list to the patch saying, for future reference, the commit message neefds improvement
08:54 tzimmermann: jani, isn't the point of PRs that someone looks over it? using an LLM kind a makes it pointless
08:54 jani: tzimmermann: looking over the commits is not exactly the same as writing a (draft) summary of it, is it?
08:55 jani: sure, a lazy maintainer could then skip over the part looking at problematic commits
08:56 jani: and if you detect it at that point, the process failed already, tbh
09:00 tzimmermann: jani, it's the same thing for me at least. i go over commits and cover letters. once i understand what it is about, i can easily write down a bullet point in the changelog
09:02 jani: tzimmermann: I guess. it's just that too often the commit messages focus on the *what* and there's zero clue why the change is being done, and what the impact, if any, to the user will be. sometimes you dig into it, and you realize it's a fix, but there's no Fixes or issue reference. :/
09:02 jani: /whine
09:02 tzimmermann: so true :D
09:04 jani: the "why" part isn't getting easier with LLMs either. you have a patch, and the LLM is great at documenting *what* the patch does, in great detail and perfect grammar. and you're still none the wiser why the change is being done
09:04 tzimmermann: phasta, servers appear to be working again
09:08 pq: jani, don't you have the power to refuse to send patches upstream if they don't describe the "why"?
09:14 jani: pq: there's 200 good patches merged in a non-rebasing -next branch. there's a few bad apples in there, good changes but poor commit messages. the chances of me reverting commits based on that are pretty low, even if I superficially have the power
09:18 jani: does sashiko ever complain about commit messages, btw? it should
09:19 jani: I've seen it dig out incredible technical issues from my patches and patches I've reviewed. but not say, "hey this commit message could use some work"
09:37 airlied: jani: I'm mostly happy with the PRs I get, because if they were perfect and I could cut-n-paste them, I'd probably stop reading them :-)
09:38 airlied: sometimes amd and misc get a bit too summarised and I end up git logging to make sure I understand
09:40 airlied: if we are adding CI to the mix I'd rather it was very staged and maintained as much of the current workflow as possible
09:41 airlied: I'd be happy if every PR I get now was in an MR that went through CI before I picked it up for -next, and if it failed CI the sender would work to resolve problems before I got it
09:42 airlied: just not sure how to deal with the next level down, maybe nightly CI on -misc-next, -intel-next so maintainers can see when sometihng was added and broke it
09:42 airlied: but I'm not sure how we get pre-merge CI onto something like misc yet
09:46 sima: jani, yeah pr feedback is a bit a case of "no feedback just means you do a solid job"
09:46 sima: at least when I reply it tends to only be because something isn't how it should have been
09:47 sima: same issue as usual with good work simply being assumed to be the default :-/
09:59 pq: Acknowledgement emails to PRs and patches are not a norm?
10:10 pq: airlied, if you stopped reading PR changelogs if they were "perfect", what would your role become? Are you not a high level gate keeper of sorts foremost?
11:03 airlied: I don't usually acknowledge PRs because my workflow doesn't come with a nice way to do it, I just lei to suck down all the git pull emails, but I've no outbound email setup to reply to them with on that system
11:04 airlied: so if I do it there is usually a reason that justifies me opening up gmail and finding the pull request to reply to manually
11:20 pq: I see.
11:21 pq: People are accustomed to polling upstream branches to see if their PRs or patches went through?
11:28 tjaalton: eric_engestrom: hey, 26.2.4 is delayed?
12:44 lucaceresoli: mripard: pinchartl: lumag_: drm bridge hotplug RFCv2 sent; the cover letter has a "For reviewers with limited time for review" section listing the few crucial patches, in case you have a moment to look at those before a discussion at LPC/ELCE
12:56 MrCooper: pq: there's a "pr-tracker-bot" which follows up to the PR mail when Linus merges it to his tree
13:00 rodrigovivi: sima airlied: dim pr of fixes is failing with a lot of complains of patches outside drm missing links and other stuff... I'm wondering if this is because drm/drm-fixes is not yet on 7.3-rc5
13:10 eric_engestrom: tjaalton: yes; I'm at XDC and when I tried to run the release notes generation script it crashed, and I figured between talking to the people there and debugging the script, I wanted to make use of the time for people and the release would come later 😅
13:11 eric_engestrom: Maybe I should've said so here last night to not leave people guessing, sorry about that
13:11 tjaalton: that's fine
13:12 tjaalton: as long as the release is today? :)
13:20 eric_engestrom: I'm going to have a little bit of time now-ish to look into that, and otherwise I'll have a couple of hours later today when I'm waiting for my flight; I'm guessing/hoping whatever the issue is, it will be fixed within that time
13:21 eric_engestrom: (or I might have to buy in-flight internet and continue there haha)
13:48 tjaalton: ack, thanks!
14:04 sima: rodrigovivi, hm maybe, I've fast-forwarded drm-fixes in case that's it
14:11 rodrigovivi: sima, that helped, thank you
14:14 sima: yay
14:16 dcbaker: eric_engestrom: I can also help out with release stuff today if that helps
14:45 eric_engestrom: dcbaker: thanks! I just got around to running it again, and it actually works now (hotel wifi), so I think it might have been a network issue at the venue (something blocked by the venue, or the venue's ip triggering stricter protections from gl.fd.o, or something like that)
14:53 eric_engestrom: tjaalton, dcbaker: 26.2.4 is now out :)
14:54 dcbaker: \o/
15:33 cheetahpixie: hello. is there a more general channel for talk about the driver?
15:34 cheetahpixie: additionally, are there channels specific to individual drivers within mesa?
15:34 cheetahpixie: I had mostly a few questions on lima specifically.
15:34 cheetahpixie: if here is where to ask, do let me know.
16:21 Company: cheetahpixie: drivers do have their own channels, but you usually get answers here, too
16:22 Company: just maybe not atm because people are at XDC (or traveling back)
16:49 mripard: lucaceresoli: I'll be at Plumbers, but I think I'll take a step back on the review side of things for the next couple of months, so I'd encourage you to ping other drm, drm-misc or bridge maintainers, reviewers, or contributors about this
17:16 cheetahpixie: ah. I had no idea that was on. Company
17:17 cheetahpixie: either way, I believe it is lima's fault that the desktop on my banana pi m1 is as slow as it is
17:17 cheetahpixie: it also has lots of dips in games, and even openarena is full of visual glitching.
17:20 f_: cheetahpixie: there is #lima here on oftc
17:20 f_: but I asked lima questions here in the past too and it was fine
17:21 f_: cheetahpixie: what desktop are you running? sway works fine for me, but openarena I had to mess around in the setting to get it to be somewhat playable, still a bit glitchy
17:22 f_: I've wanted to try debugging it to write a proper bug report but I didn't get to it
17:22 f_: this is on mali400
17:25 cheetahpixie: I'm on plasma. that's what I usually use.
17:25 cheetahpixie: as to the glitches; yes, disabling the extensions helps, but does not eliminate them
17:25 cheetahpixie: and yup, I'm on mali400 too.
17:25 cheetahpixie: tried sauerbraten. it ate hot shit trying.
17:25 cheetahpixie: /newmap had one 1s long frame of fine rendering, and then poof went the floor
17:26 cheetahpixie: I'm also realizing you might be just about everywhere, f_
17:27 cheetahpixie: uboot, towboot, here, etc. both irc and matrix
17:27 cheetahpixie: what next, debian too? :P
17:28 cheetahpixie: also, yes. that's what I'm running on; debian testing.
17:28 cheetahpixie: installed, with some snags, through the debian installer itself, with uefi.
17:28 f_: nah not debian
17:28 cheetahpixie: ah, at least it's one place you're not
17:28 f_: oh yeah I did try plasma mobile and it was fine
17:29 f_: not the most smooth but it was good
17:29 cheetahpixie: I also installed openbox on that machine, and it actually had more trouble with fps than wayland.
17:29 cheetahpixie: it does not matter what, wayland just keeps surprising me
17:29 cheetahpixie: as to the smoothness; as I said, I believe a fair amount of it is down to the gpu.
17:30 cheetahpixie: given that even openbox is chugging along on x11, and that it, as opposed to plasma, is light on writes to disk, that kinda leaves just one option
17:30 cheetahpixie: and no, it isn't ram. the system is more than happy on one gig and zram for fallback.
17:31 cheetahpixie: like 300m ish used of system ram, and ~10-15% cpu.
17:31 cheetahpixie: so it has no reason to not be smooth, really. besides of course the gpu drivers being not exactly perfect
17:31 cheetahpixie: which openarena proved.
17:37 f_: I am on 2 GB of RAM
17:40 f_: and yeah I would expect it to be slow with gaming... but openarena isn't an intensive game
17:41 f_: though I think I have a feeling that OpenGL 2.1 support in particular is not perfect
17:41 f_: as I understand it these GPUs never officially supported OpenGL 2.1
18:28 tjaalton: eric_engestrom: \o/
19:02 cheetahpixie: according to mesamatrix, lima doesn't even have all the required extensions for ogl 2.1 f_
19:18 mntirc: hmm, got all kinds of weird GL issues with the latest mesa from git on qcs8550 (fd740). firefox crashes after startup, gnome desktop also crashes when opening any app, and glmark2-es2-wayland perf under sway is quite bad
19:19 f_: cheetahpixie: yeah that's what I'm thinking
19:20 f_: cheetahpixie: not surprising, gl2.1 is a bit of a stretch for this hardware
19:22 cheetahpixie: yeah, unsurprisingly
19:22 cheetahpixie: but still
19:22 cheetahpixie: openarena should just work
19:23 cheetahpixie: after all, q3 worked way back when on much less capable hardware.
19:24 f_: yeah
19:24 cheetahpixie: yup, 1999.
19:24 cheetahpixie: even the extensions should be fine.
19:28 f_: ok with my current OpenArena settings, it works all fine, just the weapons and such items appear completely white when far from them
19:31 f_: very low 640x480 res, lightning: vertex (low), flares: off, bloom: off, geometric detail: low, texture detail: lowest, texture quality: 16 bit, texture filter: trilinear
19:32 f_: Maybe with these settings (though a bit strange I have to set so low graphic details) you'll get it playable at least
19:32 f_: (like, I know Mali400 is not very powerful, but openarena really isn't an intensive game?)
19:33 f_: (I mean, Mali400's have ran slightly more intensive (I imagine) android games over the years)
19:52 cheetahpixie: f_ did you try all hud weapons?
19:52 cheetahpixie: they can at least handle 3d
19:53 cheetahpixie: I know the chaingun has some visual artifacts
19:53 cheetahpixie: railgun is entirely white
19:53 cheetahpixie: plasma gun is entirely white
20:10 funderscore: cheetahpixie: hmm not all
20:11 cheetahpixie: not all of them, but some.
20:11 cheetahpixie: shotgun seems free of them, as does the grenade launcher
20:11 cheetahpixie: forgot to check the lightning
20:12 funderscore: no I mean I didn't try all
20:12 cheetahpixie: oh
20:21 funderscore: as it turns out OpenArena is not very playable with just a touchscreen and keyboard :p
20:33 uriah: hey, when using drm_native_context=on is venus=on still important?
20:33 uriah: for qemu
20:37 cheetahpixie: funderscore heh. got otg adapters?
20:37 cheetahpixie: if so, add a hub and a kb and m
20:43 funderscore: no "otg" (this isn't even a microusb port, it's a proprietary 30-pin) support in mainline for this device
20:43 funderscore: I need to try with a BT mouse
20:56 cheetahpixie: urgh
20:57 cheetahpixie: and a bt keyboard.
20:58 funderscore: I already use a bt keyboard :D
22:27 cheetahpixie: fun. funderscore I'm a high grade arena brat, so quake/openarena is pretty much the shit for me. oh, and doom.
22:28 cheetahpixie: does make me sensitive to something being amiss.
22:28 cheetahpixie: not that that's needed with literally white models
22:28 cheetahpixie: though I notice the pickups regain their colors in the same radius as that nearsighted thing with extensions on