03:33mareko: Ristovski: gfx9 and newer
03:34mareko: Ristovski: olders cards support it too but Mesa doesn't implement it there
07:53MrCooper: anholt: only detached pipelines have the sanity job, fork pipelines don't
08:03emersion: danvet: sorry to pull you into this, but i'm hitting pushback from the "detect chromeos" patch in amdgpu
08:04emersion: apparently some people don't like current->comm workarounds
08:19airlied: mlankhorst, thellstrom, danvet : I've left an i915 gt conflict in drm-tip, can one of you fix it up?
08:19airlied: i915_gem_ttm.c conflict
08:19airlied: I've been merging all day and my brain isn't wanting to work this one out
08:20airlied: please also verify the drm-next merges I just pushed are correct, there was a lot of conflicty bits around i915/ttm
08:34mlankhorst: That file's a pain
08:34mlankhorst: thellstrom: can you look? It's related to your object creation rework
09:56MrCooper: Plagman: re https://gitlab.freedesktop.org/drm/amd/-/issues/1740 , not seeing much activity by DC folks on GitLab issues, so I'd suggest pinging them directly by e-mail or some other channel
10:01emersion: ^ cc hwentlan agd5f siqueira
11:36danvet: emersion, link to that pushback?
11:48emersion: danvet: https://lore.kernel.org/linux-next/20211009155718.50655bd8@canb.auug.org.au/T/#mc06331f30473cbfcd87ff0eafd751e6d56bdc87a
11:49emersion: aside: kernel community as welcoming as ever
11:50danvet: ah hch :-(
11:51danvet: emersion, 26b1d3b527e7bf3e24b814d617866ac5199ce68d for precedence and how it's done
11:52danvet: agd5f, ^^
11:53danvet: hwentlan, ^^ probably too
11:53danvet: I don't have f4f80155e6e8 anywhere ...
11:54danvet: agd5f, did you move your next tree or dropped this one already?
13:13agd5f: danvet, dropped it since it doesn't build properly against 5.15
13:13agd5f: will re-add once we sort it out
17:03sravn: danvet, do you consider kernel-doc warnings fixes as drm-misc-fixes material? I am reluctant as this is not urgent fixes
17:04sravn: danvet, https://lore.kernel.org/dri-devel/20211010224459.3603-1-rdunlap@infradead.org/
17:11sravn: tzimmermann, mlankhorst, mripard ^^ - I think this Q is more for one of you
17:35Plagman: MrCooper: yeah i've reported it directly as well and pointed at that bug as a source of info for reference
17:35Plagman: thanks!
17:37Plagman: emersion: danvet: it seems to really suck that we're the ones getting yelled at just because the thing that broke us wasn't caught right away
17:43tzimmermann: sravn, unless the docs are misleading i wouldn't consider -fixes
17:46Plagman: danvet: looking at precedence, it seems to only be a subset of simon's change (only checking comm instead of comm+exe) and Christoph also seems to take issue with the idea of checking comm in the first place
17:46Plagman: also i guess any process that starts with 'X' is disallowed from atomic? good thing we're not Xgamescope
18:02emersion: yeah X is a forbidden letter now :P
18:02emersion: Plagman: indeed, if we wanted to be annoying we could argue that the chromeos fix is a kernel regression and get it reverted
18:02Plagman: yea
18:03emersion: but sending patches to make everyone happy is better
18:03Plagman: clearly it's not making everyone happy
18:03emersion: … sigh
18:06Plagman: i don't think i got anything useful as to how to move forward from the chrome people, let me go back and re-read again
18:07emersion: i've just re-sent the patch with the conflict fixed
18:08emersion: i haven't heard from the ChromeOS folks at all…
18:10Plagman: i did send a note but i don't think we got much useful out of it as to how to deal with this short-term other than value jugment on amd hardware and indeterminate plans for the future
18:10Plagman: if you resend goes up in flames i vote we get it reverted
18:11Plagman: your*
18:16emersion: if we don't have a choice, i think that would make sense: iirc chromeos has internal trees anyways? so they could keep the patch in their tree
18:17emersion: until they get it fixed
18:17bnieuwenhuizen: weren't Rob or Emma saying something about that when it was initially discussed here?
18:17emersion: yeah, they have chromeos quirks for msm
18:18emersion: but i haven't found these in mainline
18:18emersion: so i assume they are in google trees
18:18emersion: cc robclark ^
18:19Plagman: for some reason that thread isn't making it in my inbox but going by the archive link you posted, there also seems to be a lack of maintainer input in there
18:19Plagman: if it got accepted in a maintainer tree it seems like the discusison should be more between core maintainer and leaf maintainer than individual devs getting screamed at, or that they should at least participate
18:20Plagman: i appreciate moral support on irc but maybe insufficient in this case
18:21robclark: emersion, Plagman: yeah, I think we can keep workarounds for CrOS bugs in CrOS trees.. that is what we've been doing for snapdragon/msm.. but btw, what thread is this?
18:21emersion: robclark: https://lore.kernel.org/linux-next/20211009155718.50655bd8@canb.auug.org.au/T/#mc06331f30473cbfcd87ff0eafd751e6d56bdc87a
18:21robclark:looks
18:21emersion: hm seems like dri-devel isn't even CC'ed
18:22Plagman: i see lkml according to the archive but it's not n my linux-kernel inbox somehow
18:22Plagman: and i don't think i have a linux-next folder where that would have landed..
18:23emersion: do you have an "utter crap" filter which makes it go directly to spam? :P
18:24emersion: yeah LKML seems to be CC'ed…
18:24robclark: emersion, agd5f, I think drop the CrOS workaround upstream.. and then implement it in a much simpler way (ie. not bothering to need to check the userspace process) in CrOS kernel tree
18:25emersion: siqueira hwentlan agd5f ^ sounds reasonable?
18:25agd5f: emersion, robclark sounds fine to me
19:10Venemo: HayashiEsme: depends on your areas of interest. any place is good to start
19:11Venemo: which driver do you want to contribute to?
19:24emersion: thanks agd5f
19:25Venemo: correct
19:25Venemo: I think it's best to start with something that motivates you personally, on hardware that you have now
19:25danvet: Plagman, emersion I'm way behind on email, but imo comm check gets my ack
19:25danvet: maybe poke airlied for this too
19:26danvet: Plagman, also note that you can still get atomic if your Xgamescope
19:26danvet: you just need to ask for atomic v2
19:26danvet: so we weren't completely silly
19:26Plagman: ah yea
19:26danvet: ofc assuming agd5f is fine with the comm check only
19:28Venemo: there are difficult bits and pieces everywhere
19:28Venemo: just don't be afraid to ask questions if you're stuck
19:28Venemo: we're here for you
19:29Plagman: i think emersion's v2 still also gets the exe, just from some other spot that doesn't require that export?
19:34airlied: I'm not a big fan of the exe probing tbh, since it's unversioned and has no great info in what needs to be fixed in userspace
19:35airlied: like the X atomic one was pretty nutso that we had to do that
19:35airlied: I'm not sure it should set a precedent
19:37robclark: IMO, no real good reason for carrying CrOS workarounds upstream other than for testing upstream kernels if things are *completely* broken otherwise (and in that case maybe guard it w/ a modparam instead)
19:37robclark: otherwise we can carry workaround downstream.. and drop it in sync with userspace getting fixed
19:38robclark: for snapdragon/msm case.. the issue worked around is a bit more of an edge case, so doesn't get in the way of upstream testing
19:41Venemo: HayashiEsme: if you want to start with iris, then Kayden and jekstrand are the people who may help you get started
19:43robclark: Venemo, HayashiEsme, jfyi only Venemo's side of the conversation is showing up (so I guess you are both using matrix but one of you is not identified with NickServ?)
19:44Venemo: Oh yes that can happen if you are connected through Matrix
19:44Venemo: robclark can't see what you write as long as you're not authenticated
19:44robclark: (just mentioning because I guess Kayden and jekstrand are also not seeing the other half of the conversation either ;-))
19:46HayashiEsme[m]: Gosh, can everyone of OFTC see this now?
19:46bnieuwenhuizen: yea
19:46HayashiEsme[m]: \o/!!
19:46HayashiEsme[m]: Oh my goodness that would explain a lot
19:46Venemo: best way to make sure is to take a look at these logs: https://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&date=2021-10-11
19:46HayashiEsme[m]: Thanks for pointing that out @robclark, NickServ is usually pretty good at telling me I'm doing something silly
19:47HayashiEsme[m]: Yeah I had been trying to say hi ...but clearly only to people connected to matrix via OFTC 🤦♀️
19:48HayashiEsme[m]: I'm being chased out of the bedroom by the boyfriend but I'll properly say hi in a bit, bbl -- whoops on the NickServ thing bah
19:49HayashiEsme[m]: OFTC via matrix*
19:55Venemo: no worries
19:56Venemo: happened to me as well at some point
20:01anholt: sweet. new gtest-runner for doing vaapi unit tests seems to be basically working.
20:55eric_engestrom: quick reminder that the mesa 21.3 branchpoint is in a bit less than 48h :)
20:56eric_engestrom: (as usual, I'm planning on doing it at around 6pm UTC, just so that you don't wait until EOD US time :)
22:02HayashiEsme[m]: Goodness, I'm surprised I hadn't been barred from posting at all without registerring my nick, but here's a pastebin of the conversation between venemo and I - since I had been doing so through Matrix and not also through OFTC https://paste.ubuntu.com/p/MfwdgF6fDw/
22:44anholt: tomeu: seen a couple of nfs timeouts from lava recently https://gitlab.freedesktop.org/mesa/mesa/-/jobs/14603067#L2706