07:20 Venemo: looks like current amd-staging-drm-next doesn't compile thanks to this error: https://pastebin.com/raw/vhWHx98Y
07:27 Ermine: could be something about gcc. I've saw a similar error in another channel
07:47 Venemo: yeah
08:20 Venemo: there is also
08:20 Venemo: arch/x86/tools/insn_decoder_test: error: malformed line 5977902: 2_>:ffffffff81f188e0
08:20 Venemo: make[2]: *** [arch/x86/tools/Makefile:26: posttest] Error 3
08:39 Venemo: Now I wonder if maybe I'm not building the correct version
08:43 Ermine: What's your toolchain and awk versions?
08:46 Venemo: Ermine: I don't know what awk is, I just cloned agd5f's repo and building amd-staging-drm-next
08:46 Venemo: but this branch seems to be missing some patches that were sent to mainline months ago
08:47 Venemo: if I run 'sudo make modules_install install' it is recognized as "6.14.0+" which just seems wrong
08:52 Ermine: i have 6.14.0+ as well. That seems usual for driver/subsystem trees
08:54 Venemo: seems like a rebase is overdue
08:55 Ermine: Venemo: insn decoding test uses awk tool, and it can be theoretically broken
08:56 Ermine: awk --version
08:56 Venemo: Ermine: no, it's just missing a patch
08:56 Venemo: it was fixed by c250b0723a61160521c87c8e837baa54c13506fc some time ago, just amd-staging-drm-next doesn't include that patch as it is still based on 6.14
08:57 Venemo: the string initialization thing was addressed by 9e2a872c144729b149a4b0de2fac5c254e078b2b - also not included in amd-staging-drm-next
08:58 Ermine: i've built amd-staging-drm-next last Thursday successfully
09:01 Venemo: me too, with those two patches cherry-picked
09:01 Ermine: i didn't cherry pick those patches though
09:02 Venemo: maybe we use a different version of gcc or something
09:02 Venemo: gcc 15.1.1 here
09:03 Ermine: i have gcc 15.1.1 too probably. *shrug*
09:03 Venemo: I remember both of those errors showing up when building the mainline kernel some months ago
09:06 Ermine: from which tree have you picked those commits?
09:08 Venemo: ayy, when pasting them I forgot that git changes the sha after you cherry pick them, sorry
09:12 Venemo: they are: https://github.com/torvalds/linux/commit/c104c16073b7fdb3e4eae18f66f4009f6b073d6f and https://github.com/torvalds/linux/commit/9d7a0577c9db35c4cc52db90bc415ea248446472
09:19 Venemo: maybe the respective issues don't trigger with your config and do with mine, for some reason
09:20 Venemo: anyway. looks like I made a mistake writing my patches on top of upstream because now it's a hassle to port them to amd-staging-drm-next
09:21 Venemo: DC on SI is even more broken than it was on upstream
09:22 MrCooper: Venemo: amd-staging-drm-next is AMD's problem, not yours
09:23 MrCooper: submitting patches against upstream is fair game
09:23 Venemo: MrCooper: I'd like to send some patches to them, so I assume it has to be applied to amd-staging-drm-next
09:23 MrCooper: not really
09:23 MrCooper: I've never done that (maybe it didn't make a difference for my patches though)
09:24 Venemo: well
09:25 Venemo: I would appreciate if you could explain the correct process then, MrCooper
09:25 Venemo: I thought the right way to send patches to amdgpu and DC is to send them to the amd-gfx mailing list, and then they will be applied to amd-staging-drm-next
09:26 MrCooper: that's correct, the patches can be against upstream though, in which case any issues with amd-staging-drm-next are up to AMD devs to handle
09:27 Venemo: well, I'd like to make it easy for them to handle
09:27 MrCooper: it's up to you if you want to go that extra mile
09:28 Venemo: I think it will be easier for the patches to be accepted if they actually work on the tree on which they will be applied
09:28 MrCooper: that's ultimately not amd-staging-drm-next though
09:29 Venemo: well what is the process then?
09:29 Ermine: i thought it was an imperative to send patches against a relevant tree...
09:29 Venemo: I thought so too
09:29 MrCooper: amd-staging-drm-next is never merged into Linus' tree
09:30 MrCooper: as the name implies, it's a staging branch for AMD's internal use
09:30 Venemo: I thought the way it works is that the maintainers of amdgpu send a pull request for drm-next, and then the drm maintainers send a pull request to upstream, is that an incorrect understanding of what the process is?
09:31 MrCooper: that's correct, doesn't involve amd-staging-drm-next though
09:31 MrCooper: Alex creates a new drm-next-<major>.<minor> branch for this every cycle
09:32 Venemo: okay, I think Alex isn't online right now but when he comes back I'll ask him what his preference is
09:32 MrCooper: good idea
09:33 Venemo: or maybe airlied can shed some light on this
09:38 Venemo: anyway, amd-staging-drm-next does have a regression that I want to diagnose so I still would like ot fix that
09:59 Venemo: MrCooper: do you know if it's possible / feasible to remove amdgpu from fedora's initramfs?
10:01 MrCooper: I expect it's possible via /etc/dracut.conf.d/, I don't know the magic incantation by heart though
10:02 MrCooper: dracut.conf manpage says it's omit_drivers
10:06 Venemo: will it result in a bootable system, though?
10:17 MrCooper: can't think of any reason why it wouldn't offhand
10:18 MrCooper: only one way to be sure though :)
10:19 MrCooper: what do you want that for though?
10:24 Venemo: it is tedious to have to rebuild the whole initramfs every time I make a change to amdgpu
10:24 Venemo: I am hoping to be able to skip that
10:24 MrCooper: makes sense
10:27 Venemo: looks like "drm/amd/display: Refactor DSC cap calculations" broke DC on GFX6-8 (I haven't tested others though)
15:47 johnny0: Venemo: just rebuilt asdn with gcc 14.2.0, I'm not seeing an immediate issue with DC on GFX7 (with DP 1.2 monitor + edid override)
15:49 Venemo: johnny0: I only tested with Oland (gfx6) and Fiji (gfx8), both were broken.
15:50 Venemo: after a bisect, this is what broke them: https://gitlab.freedesktop.org/agd5f/linux/-/commit/4909b8b3846c9d64dd4aa48df21d3abe1b9495a6
15:50 Venemo: it's a divide by zero
15:50 Venemo: this fixes it for me: https://gitlab.freedesktop.org/Venemo/linux/-/commit/374b51b3f1e173a29e7078bb2edb346ec4da8196
16:20 johnny0: interesting, with what type of monitor? or busted even without one connected?
16:21 Venemo: it's a 4K 144Hz Samsung.
16:22 Venemo: I assume the main trigger for the issue is that this monitor supports DSC but the GPU doesn't
16:22 johnny0: yeah, would make sense, mine is definitely *not* a DSC monitor
16:23 Venemo: it is frightening how this stuff can get broken in so many subtle ways
16:33 Venemo: I've fixed a ton of stuff to get DC working on SI and I'm still not fully sure if I got everything right
17:01 johnny0: a bit daunting for sure