16:30fdobridge: <![NVK Whacker] Echo (she) 🇱🇹> Why does the part 2 of GSP patches add NVDEC/NVENC support? Could this mean HW video encoding might be possible again? 🍩
16:39fdobridge: <esdrastarsis> Maybe vulkan video?
16:40fdobridge: <esdrastarsis> dave airlie did some work iirc
16:40fdobridge: <karolherbst🐧🦀> we have to manage the engines even if we don't do anything with those
16:44fdobridge: <![NVK Whacker] Echo (she) 🇱🇹> How simple is the management of them?
16:49fdobridge: <karolherbst🐧🦀> with GSP pretty simple
16:54fdobridge: <![NVK Whacker] Echo (she) 🇱🇹> Why are there no NVIDIA or GSP emotes here?
16:55fdobridge: <orowith2os> *NoVideo
16:57fdobridge: <karolherbst🐧🦀> create them
16:57fdobridge: <karolherbst🐧🦀> or link them
16:57fdobridge: <karolherbst🐧🦀> or whatever
17:04fdobridge: <![NVK Whacker] Echo (she) 🇱🇹> LGD already has 2 NVIDIA emotes
17:43fdobridge: <esdrastarsis> To support hwmon, is it necessary to implement the openrm "platform" module?
17:44fdobridge: <karolherbst🐧🦀> what do you mean by that?
17:44fdobridge: <karolherbst🐧🦀> we can do all of that inside nouveau
17:44fdobridge: <esdrastarsis> https://github.com/NVIDIA/open-gpu-kernel-modules/tree/main/src/nvidia/src/kernel/platform
17:44fdobridge: <esdrastarsis> I mean, implement platform inside nouveau
17:45fdobridge: <karolherbst🐧🦀> I mean.. dunno.. it kinda depends on what gsp provides us and how that would all fit in
18:14fdobridge: <airlied> I wonder if they provide thermal info in a user object
18:16fdobridge: <airlied> Like we have therm now but I think that might be nouveau invented
18:23fdobridge: <airlied> Oh looks like Linus merged gsp, time to start hammering in the fixes
18:27fdobridge: <![NVK Whacker] Echo (she) 🇱🇹> Hopefully it will eventually survive the Vulkan CTS hammer
18:32fdobridge: <conan_kudo> do you plan to submit the gsp firmware to linux-firmware?
18:37fdobridge: <karolherbst🐧🦀> I wonder how many distributions we'll mess up with gsp...
18:38fdobridge: <karolherbst🐧🦀> but maybe it's finally the moment where everybody will move firmware files out of initramfs and fix a bunch of rando bugs while at it
18:38fdobridge: <karolherbst🐧🦀> so win-win
18:40fdobridge: <airlied> I think Timur will send it or I will this week
18:40fdobridge: <karolherbst🐧🦀> @airlied do we talked with Nvidia if they'll notify us if we have to update GSP?
18:41fdobridge: <airlied> We can't update so it's all fine
18:41fdobridge: <karolherbst🐧🦀> or is it "we'll upgrade to every single version"
18:41fdobridge: <airlied> No we won't ever upgrade until we have to support new hardware is current plan
18:42fdobridge: <karolherbst🐧🦀> yeah, and will nvidia notify us?
18:42fdobridge: <karolherbst🐧🦀> because.. if they won't, we'll have to update to every single version
18:42fdobridge: <karolherbst🐧🦀> or wait for bugs
18:42fdobridge: <airlied> I assume Timur will tell us
18:42fdobridge: <karolherbst🐧🦀> given my past experience with nvidia on this, I highly doubt that unless they promise us
18:42fdobridge: <karolherbst🐧🦀> in writing
18:43fdobridge: <airlied> Why do you think we need to update to every release though?
18:43fdobridge: <karolherbst🐧🦀> and even then I'd think it's 50:50
18:43fdobridge: <airlied> Just not seeing the connection
18:43fdobridge: <karolherbst🐧🦀> because past experience
18:43fdobridge: <airlied> Still not seeing it
18:43fdobridge: <karolherbst🐧🦀> we needed to update pascal firmware
18:43fdobridge: <karolherbst🐧🦀> same for turing
18:43fdobridge: <karolherbst🐧🦀> to support newer GPUs
18:43fdobridge: <airlied> That fw was for nouveau
18:43fdobridge: <karolherbst🐧🦀> yeah
18:43fdobridge: <karolherbst🐧🦀> but same would have happened with nvidia firmware
18:43fdobridge: <karolherbst🐧🦀> they needed newer firmware no matter what
18:44fdobridge: <airlied> Like we can see the supported GPUs json
18:44fdobridge: <karolherbst🐧🦀> it means nothing
18:44fdobridge: <airlied> Yes it does, they generate it
18:44fdobridge: <karolherbst🐧🦀> new batches of GPUs will require updated firmware
18:44fdobridge: <karolherbst🐧🦀> even if the PCI IDs are same
18:44fdobridge: <conan_kudo> also whenever they respin the GPU SoCs
18:44fdobridge: <airlied> Yes so when the json updates for new GPUs we will have to get it
18:44fdobridge: <conan_kudo> which happens every six months
18:44fdobridge: <karolherbst🐧🦀> and when we asked them they said "we know of nothing"
18:44fdobridge: <conan_kudo> which happens every six months (more or less) (edited)
18:45fdobridge: <karolherbst🐧🦀> so my trust on this is pretty much 0%
18:45fdobridge: <karolherbst🐧🦀> it's not about new chipsets/models/whatever
18:45fdobridge: <karolherbst🐧🦀> it's about GPUs with existing chipsets
18:45fdobridge: <karolherbst🐧🦀> nothing changes
18:45fdobridge: <airlied> Oh great yeah no idea if they even know that info
18:46fdobridge: <karolherbst🐧🦀> so yeah...
18:46fdobridge: <karolherbst🐧🦀> I mean.. we can wait for bugs and then just try if newer GSP fixes it
18:46fdobridge: <karolherbst🐧🦀> but...
18:46fdobridge: <karolherbst🐧🦀> that's not a good model here
18:46fdobridge: <airlied> Yes it'll be that most likely
18:46fdobridge: <karolherbst🐧🦀> maybe we should ask them very very explicitly to tell us ahead of time
18:46fdobridge: <karolherbst🐧🦀> and see what happens
18:47fdobridge: <airlied> That assumes they know themselves of course
18:47fdobridge: <karolherbst🐧🦀> yeah...
18:47fdobridge: <karolherbst🐧🦀> which appeared they didn't
18:47fdobridge: <karolherbst🐧🦀> firmware crash dump helped to figure that out
18:48fdobridge: <karolherbst🐧🦀> maybe we can ask them for changelogs...
18:48fdobridge: <airlied> We won't be pulling in a newer version until we figure out an abstraction
18:48fdobridge: <airlied> Otherwise it will be even more umanageable
18:49fdobridge: <karolherbst🐧🦀> mhh
18:49fdobridge: <karolherbst🐧🦀> I guess we should already figure out an abstraction as we probably gonna need it
18:49fdobridge: <karolherbst🐧🦀> I don't see why it wouldn't given it happened with like the past three gens (where ampere is still TBD tho)
18:49fdobridge: <airlied> Dakr is starting on it soon, feel free to help him 🙂
18:50fdobridge: <karolherbst🐧🦀> yeah.. hopefully we won't have to do it tooo often
18:51fdobridge: <conan_kudo> I think recently NVIDIA said they're going to move to releasing new GPU generations yearly instead of slowing down to two years...
18:51fdobridge: <karolherbst🐧🦀> I think I'm mostly just frustrated, because uhh.... it's pain
18:52fdobridge: <karolherbst🐧🦀> ehhh
18:52fdobridge: <karolherbst🐧🦀> so every year 35MB firmware blobs, also great
18:53fdobridge: <![NVK Whacker] Echo (she) 🇱🇹> ```
18:53fdobridge: <![NVK Whacker] Echo (she) 🇱🇹> # Main GSP blob (this is over 20 MB (or 30 MB for Ampere) somehow)
18:53fdobridge: <![NVK Whacker] Echo (she) 🇱🇹> # Interesting article about this: https://www.phoronix.com/news/NVIDIA-GSP-Firmware-Bloat
18:53fdobridge: <![NVK Whacker] Echo (she) 🇱🇹> ```
18:53fdobridge: <conan_kudo> Michel, Davide, and I have been renewing our efforts on refactoring how the linux-firmware package works in Fedora because we _really_ need to adopt the openSUSE-style kernel-firmware packaging where we can bind firmware packages to kmods and modaliases
18:54fdobridge: <karolherbst🐧🦀> if it moves firmware files out of initramfs I'm all for it
18:54fdobridge: <conan_kudo> well, where it lives is dependent on driver infrastructure
18:54fdobridge: <conan_kudo> we can't pull it out of initramfs until we figure out how to handle that
18:54fdobridge: <karolherbst🐧🦀> I'm sure each distribution will see themselves forced moving those files out anyway
18:54fdobridge: <karolherbst🐧🦀> it's just a matter of time at this point
18:54fdobridge: <mohamexiety> other way around, no?
18:55fdobridge: <mohamexiety> 5000 series is rumored to be 2025 lol
18:55fdobridge: <conan_kudo> No. This was recent. Apparently they're being challenged at the pro/dc level and are planning to spin new stuff yearly again.
18:55fdobridge: <mohamexiety> oh dc
18:55fdobridge: <conan_kudo> consumer GPUs may wind up still being every two years, who knows
18:56fdobridge: <mohamexiety> yeah I haven't been following the dc stuff
18:56fdobridge: <conan_kudo> all the AI/ML and codec stuff has been pushing them hard
18:56fdobridge: <airlied> I will rebase the fw grouping stuff, though it's pretty messy
18:57fdobridge: <airlied> Should at least allow initramfs to only need one or maybe two
18:57fdobridge: <conan_kudo> that'd be great
18:58fdobridge: <![NVK Whacker] Echo (she) 🇱🇹> 2 firmwares for 3 generations 💪
18:58fdobridge: <conan_kudo> @karolherbst I think that there will be less pressure than you expect for moving it out of initramfs since we have hostonly mode in dracut
18:58fdobridge: <conan_kudo> I don't think we've been selective about pulling firmware files in, but that's probably the first thing that'll change
19:01fdobridge: <karolherbst🐧🦀> but you can't access that with FDE can you?
19:01fdobridge: <conan_kudo> sure you can
19:01fdobridge: <conan_kudo> we generate the initramfs in the running system anyway
19:01fdobridge: <karolherbst🐧🦀> sure
19:01fdobridge: <conan_kudo> then the initramfs is installed into a part of the disk that isn't encrypted
19:01fdobridge: <karolherbst🐧🦀> but those files are still huge
19:01fdobridge: <conan_kudo> then the initramfs image is installed into a part of the disk that isn't encrypted (edited)
19:01fdobridge: <airlied> But there is a push to pregenerate them again
19:02fdobridge: <airlied> For measuring boot
19:02fdobridge: <conan_kudo> the UKI stuff will fail in the face of this
19:02fdobridge: <karolherbst🐧🦀> I honestly don't see how keeping those files in initramfs has any benefits compared to just copying them into `/boot`
19:03fdobridge: <conan_kudo> the main benefit is ensuring the graphical early boot environment works, but that's pre simpledrm, I guess that could be fixed now we have it
19:03fdobridge: <airlied> Don't think we can access /boot
19:03fdobridge: <airlied> But a second initramfs with just fw would work
19:03fdobridge: <airlied> Generating it would need changes
19:03fdobridge: <karolherbst🐧🦀> oh yeah.. or an firmware only initramfs shared across all kernels
19:03fdobridge: <karolherbst🐧🦀> that would be fine as well
19:03fdobridge: <conan_kudo> the current problem with simpledrm right now is getting a good graphical boot mode by default
19:03fdobridge: <airlied> As you would have to aggregate all installed kernels
19:04fdobridge: <karolherbst🐧🦀> simpledrm isn't enough
19:04fdobridge: <karolherbst🐧🦀> you'll need native drivers
19:04fdobridge: <karolherbst🐧🦀> you literally can't solve this by moving to simpledrm
19:04fdobridge: <airlied> Docked laptops make simpledrm not sufficient
19:04fdobridge: <karolherbst🐧🦀> and DP-MST also doesn't always work afaik
19:05fdobridge: <conan_kudo> yes I'm aware
19:05fdobridge: <conan_kudo> I know all these things, since I had to deal with simpledrm integration for Fedora KDE
19:05fdobridge: <karolherbst🐧🦀> pain
19:05fdobridge: <conan_kudo> UKI is unrealistic except for very simple systems (VMs mainly)
19:06fdobridge: <conan_kudo> and people don't like the idea of `/boot` as a btrfs subvolume (which would alleviate the space issues)
19:07fdobridge: <karolherbst🐧🦀> I don't see how they have any other choice
19:07fdobridge: <conan_kudo> we're getting to the point that it's going to become necessary for us to ship an EFI filesystem driver
19:07fdobridge: <conan_kudo> thankfully there are two implementations of such for btrfs, one derived from GRUB code and one written from scratch by the guy who wrote the Windows Btrfs driver
19:09fdobridge: <karolherbst🐧🦀> mhhh
19:10fdobridge: <karolherbst🐧🦀> though why would that be needed?
19:10fdobridge: <conan_kudo> because Fedora is gaining support for sd-boot 😦
19:10fdobridge: <karolherbst🐧🦀> the kernel could mount `/boot` before asking for the FDE password
19:10fdobridge: <conan_kudo> yes, we could have a two-stage initramfs system again
19:10fdobridge: <conan_kudo> like we did back in the days of boot floppies
19:11fdobridge: <conan_kudo> Fedora's kernel has btrfs as a built-in, so you don't need the full initramfs for it
19:11fdobridge: <karolherbst🐧🦀> kinda sounds like the least painful option and would allow for a lot of other things
19:12fdobridge: <conan_kudo> I'm not the one to convince :/
19:27fdobridge: <![NVK Whacker] Echo (she) 🇱🇹> I'm not sure what happened here (Ben's series was fine)
19:27fdobridge: <![NVK Whacker] Echo (she) 🇱🇹> https://cdn.discordapp.com/attachments/1034184951790305330/1170806639478182149/message.diff?ex=655a61a7&is=6547eca7&hm=83c9570810f89fc38e8b22f9f80b9e884fe5ebae1160e87a0836dde1dd491a8e&
19:39fdobridge: <airlied> what are you trying to apply?
19:40fdobridge: <![NVK Whacker] Echo (she) 🇱🇹> Just some GSP stuff (the kernel compiled fine now)
19:45fdobridge: <airlied> not sure what gsp stuff means
19:45fdobridge: <airlied> all the patches are now in Linus' tree
19:46fdobridge: <![NVK Whacker] Echo (she) 🇱🇹> I mean the part 1 of GSP patches (which includes a lot of display stuff)
19:48fdobridge: <karolherbst🐧🦀> it's all in upstream now
19:50fdobridge: <![NVK Whacker] Echo (she) 🇱🇹> Not upstream enough for Arch though
19:56fdobridge: <airlied> what landed upstream isn't the same as any of Ben's old patch series though
19:57airlied: so there is likely divergence you'd have to deal with
20:07fdobridge: <![NVK Whacker] Echo (she) 🇱🇹> I did pick the upstream patches
20:07fdobridge: <![NVK Whacker] Echo (she) 🇱🇹> The merge commit deviates from the individual upstream patches a bit though
20:37airlied: Lyude: the displayless fix patch is on the list
21:04fdobridge: <airlied> it needs more wiring up in the kernel, then someone has to reverse engineer and write the userspace, but it should be possible
21:13fdobridge: <conan_kudo> that would be _awesome_