04:03 ity: Hello, is there something blocking power management for NV130, or is it marked TODO because there is nobody interested in working on it, however it *is* doable?
04:27 fdobridge: <r​edsheep> ity: It's genuinely a very difficult problem, it's not just a matter of lack of interest in solving it.
04:28 fdobridge: <r​edsheep> I've only been around here a few months but I can say that there's been significant discussion on the topic in that time, and nobody has a workable solution yet, and most of the real developers around here have more pressing things to address
04:31 fdobridge: <r​edsheep> If you wanted to work on it the approach that sounds closest to being usable would be automating extracting all of the firmware from nvidia's driver download so that the problem of working alternative firmware or redistribution of nvidia's doesn't have to get solved as those are both essentially dead ends.
04:32 fdobridge: <r​edsheep> Then the kernel would need to be taught to use that firmware. So, it's really hard.
07:05 fdobridge: <m​agic_rb.> Has anyone tested how similar the api of the two "firmwares" is? GSP and normal firmware? Because i could possibly help with the extraction part and automating that somehow. But the kernel side of things is way beyond me
07:06 fdobridge: <m​agic_rb.> \*tested -> looked/thought about/vague idea
07:12 fdobridge: <S​id> is different
07:13 fdobridge: <S​id> also we're not allowed to redistribute the other firmware iirc
07:18 fdobridge: <m​agic_rb.> Ofc, but personally if id have to fetch it myself for my 1060 to work id be happy with that
07:19 fdobridge: <m​agic_rb.> Because currently i have a very expensive paper weight as the proprietary nvidia driver has been causing more segfaults than floating point computations
08:09 ity: I am not sure I follow, what is making it difficult?
08:45 fdobridge: <S​id> we don't have any documentation on how they work
08:46 fdobridge: <S​id> and pascal firmware is signed/encrypted anyway
08:46 fdobridge: <S​id> afaik
09:10 HdkR: Signed, not encrypted
09:12 fdobridge: <m​agic_rb.> yeah but if we "ship" that precise firmware, then the signing isnt broken, the GPU allows higher power states and we "just" need to figure out how to communicate with it
09:12 fdobridge: <m​agic_rb.> and also how to spin this to the kernel maintainers so they allow code which can never be used without breaking NVidia's tos
09:13 HdkR: Sadly NVIDIA never resolved the distribution problem with those firmware blobs
09:13 fdobridge: <m​agic_rb.> well, ripping it from the update packages is an option, not a good one or an official one, but an option
09:41 ity: So, outside of the problem with distribution of the blob, how is it different from how were the graphics reverse engineered?
09:52 fdobridge: <m​agic_rb.> If i understand it correctly, nvidia gpus allow upload of firmware, its what the proprietary driver does too. Difference between nouveau and proprietary is that the nvidia one is signed by nvidia. If thw gpu doesnt get a signes one it locks itself down. From what ive heard it to combat sketchy aliexpress/wish.com gpus which report themselves as a 1080 while being a 1050 with a quarter of the vram.
09:52 fdobridge: <m​agic_rb.> If i understand it correctly, nvidia gpus allow upload of firmware, its what the proprietary driver does too. Difference between nouveau and proprietary is that the nvidia one is signed by nvidia. If thw gpu doesnt get a signed one it locks itself down. From what ive heard it to combat sketchy aliexpress/wish.com gpus which report themselves as a 1080 while being a 1050 with a quarter of the vram. (edited)
10:34 fdobridge: <S​id> it is not an option because that still becomes redistribution
10:34 fdobridge: <S​id> which we're not allowed to
10:43 fdobridge: <m​agic_rb.> yes but leaving it up to the user is not redistribution "if you want it, rip it yourself, have fun"
10:44 fdobridge: <S​id> something something providing implementation is a grey area + we don't have any kind of documentation for it
10:44 fdobridge: <S​id> something
10:47 fdobridge: <m​agic_rb.> fair, im not a nouveau developer and wont become one probably so not up to me
10:47 fdobridge: <S​id> yeah, I don't have the full picture either, but that's what I know
10:47 fdobridge: <S​id> I could be wrong, don't quote me on anything
10:47 fdobridge: <m​agic_rb.> it would be really nice of nvidia to throw us a bone on this one
10:47 fdobridge: <S​id> why
10:48 fdobridge: <S​id> they're already allowing us to properly support hardware up to 6 years old
10:48 fdobridge: <m​agic_rb.> not denying that what we have currently isn't nice, but it would be even nicer to be able to support maxwell to pascal
10:49 fdobridge: <m​agic_rb.> not denying that what we have currently isn't nice, but it would be even nicer to be able to support maxwell to pascal properly (edited)
10:49 fdobridge: <S​id> and a lot of pre-pascal cards support manual reclocking
10:49 fdobridge: <m​agic_rb.> and i dont really see how handing us a redistributable firmware would harm them too much, it still protects their products from tampering
10:50 fdobridge: <m​agic_rb.> as in, if we couldnt redistribute GSP firmware we'd be exactly in the same situation as we're with non GSP
10:51 fdobridge: <m​agic_rb.> so being able to redistribute and maybe some docs thrown over the wall would go a long way already but idk, not a dev
10:51 fdobridge: <S​id> it would, but it's not that simple for nvidia
10:52 fdobridge: <S​id> something something legal stuff, entirely possible they can't hand firmware/docs without revealing some stuff that's not-meant-to-be-revealed
10:52 fdobridge: <m​agic_rb.> yeah i know, but still, one can hope
10:52 fdobridge: <m​agic_rb.> its not like pascal is relevant anymore for them
10:53 fdobridge: <m​agic_rb.> and the 5 people that dont buy a new gpu because nouveau can properly support pascal, wont make a dent in their budget either 🤷
10:53 fdobridge: <m​agic_rb.> but yea it depends on what legal shit theyre bound by
10:53 fdobridge: <m​agic_rb.> not entirely up to them
10:53 fdobridge: <m​agic_rb.> i gotta go
10:54 fdobridge: <S​id> the thing is
10:54 fdobridge: <S​id> we're currently a stopgap
10:54 fdobridge: <m​agic_rb.> fuck, the bathroom is taken
10:55 fdobridge: <S​id> nvidia aims to upstream the openrm modules once they've managed to stabilize their ABI
10:55 fdobridge: <S​id> and one requirement for upstreaming a new kernel module is that there has to be a open-source userspace component that uses it
10:56 fdobridge: <S​id> while the proprietary driver does not fulfill that, nouveau/nvk does, meaning eventually we might have to refactor to fit the stabilized openrm modules
10:56 fdobridge: <m​agic_rb.> ah, so thats why we're allowed to exist, lol
10:56 fdobridge: <S​id> unless nv decides to release their driver as FOSS
10:56 fdobridge: <m​agic_rb.> what if we told nvidia to sod off politely
10:56 fdobridge: <S​id> but why
10:56 fdobridge: <S​id> they know the hardware the best
10:57 fdobridge: <S​id> and if they're gonna maintain the upstream module
10:57 fdobridge: <m​agic_rb.> sometimes i like to see the world burn, but yeah they do
10:57 fdobridge: <m​agic_rb.> would be fun to watch tho
10:57 fdobridge: <S​id> that's less of a workload for us
10:57 fdobridge: <S​id> ok
10:57 fdobridge: <m​agic_rb.> i wonder where this upstreaming push is coming from on their side
10:58 fdobridge: <S​id> they want to cater better to enterprise
10:58 fdobridge: <S​id> and are supposedly working with Canonical and RHEL on this
10:58 fdobridge: <S​id> oh and SUSE too
10:58 fdobridge: <S​id> also, feel free to tell AMD and Intel to "politely sod off" as well, because they have the same approach
10:59 fdobridge: <m​agic_rb.> so all the big players essentially, makes sense, its easier to ship and live patch a kernel without proprietary blobs
10:59 fdobridge: <S​id> amdgpu and i915/xe kernel modules are maintained by the respective companies
10:59 fdobridge: <m​agic_rb.> reason why i said that, is because nvidia depends on us going along with it, in their upstreaming efforts
10:59 fdobridge: <S​id> well
10:59 fdobridge: <S​id> so did AMD
10:59 fdobridge: <S​id> so did Intel
11:00 fdobridge: <S​id> ¯\_(ツ)_/¯
11:00 fdobridge: <S​id> well, maybe not intel, but AMD definitely
11:00 fdobridge: <S​id> there's a reason why AMDVLK and radv are separate drivers
11:00 fdobridge: <m​agic_rb.> dont amd and intel also maintain or help with mesa at least?
11:00 fdobridge: <p​ixelcluster> amd maintains mesa opengl
11:00 fdobridge: <m​agic_rb.> AMDGPU is open source afaik
11:00 fdobridge: <S​id> isn't there a proprietary amdgpu as well
11:00 fdobridge: <p​ixelcluster> the vast majority of radv work is not amd
11:01 fdobridge: <S​id> userspace driver, I mean
11:01 fdobridge: <m​agic_rb.> im fine with AMD and Intel because they maintain both sides at least to some degree
11:01 fdobridge: <S​id> kernel driver is foss yes sure
11:01 fdobridge: <S​id> no lol
11:01 fdobridge: <p​ixelcluster> tbf amd has amdvlk as an opensource userspace vk driver
11:01 fdobridge: <m​agic_rb.> let me rephrase "help out"
11:02 fdobridge: <p​ixelcluster> amd also has a proprietary vk driver but it isn't really relevant to the discussion
11:02 fdobridge: <S​id> nv's doing the same, karol now has a direct line of contact to their internal bug tracker
11:02 fdobridge: <m​agic_rb.> afaik AMDVLK/AMDGPU are amd drivers, while RADV is a community/valve effort
11:02 fdobridge: <p​ixelcluster> correct
11:02 fdobridge: <S​id> radv has been a thing since before valve, but yes, mesa driver
11:02 fdobridge: <S​id> afaik
11:03 fdobridge: <p​ixelcluster> and i mean amd had in-tree kernel drivers before radv, so they indeed don't "depend" on others to get their drivers in-tree as you say nvidia would
11:03 fdobridge: <S​id> yeah
11:03 fdobridge: <S​id> amdgpu used to be called radeon
11:03 fdobridge: <S​id> or something like th
11:03 fdobridge: <S​id> s\/th/that
11:03 fdobridge: <p​ixelcluster> nah radeon is a separate driver for older gpus
11:04 fdobridge: <p​ixelcluster> exists alongside amdgpu
11:04 fdobridge: <S​id> right
11:04 fdobridge: <p​ixelcluster> amd used to have an out-of-tree driver in the past too btw
11:04 fdobridge: <S​id> either way, nv deciding to support only turing and above makes sense, since their priority is enterprise
11:05 fdobridge: <S​id> they're not doing it for the linux gamers, the linux gamers getting something out of it is a side effect
11:05 fdobridge: <S​id> why does it make sense? RT/AI accelerated computing is increasingly popular, and only Turing and above have the hardware required for it
11:06 fdobridge: <S​id> le fancy "tensor cores"
11:07 fdobridge: <S​id> I do wonder how we'll handle the transition from nouveau to nvidia as our kernel driver, when they do decide to upstream
11:07 fdobridge: <S​id> or if we'll even do it at all
11:07 fdobridge: <S​id> I hope we do, would be convenient
11:08 fdobridge: <S​id> could switch between mesa and proprietary drivers by just pointing to a different icd then
11:10 fdobridge: <S​id> does it suck that we can't support every card out there? sure does
11:10 fdobridge: <S​id> but we can't do anything about it and getting mad about it now is not gonna help, for such old hardware
11:26 fdobridge: <r​hed0x> even besides that, I doubt a data center would keep old GPUs around for 7 years. The power savings of newer architectures matter a lot there
11:35 fdobridge: <b​ylaws> I mean mesa could viably support prop while it's downstream
11:35 fdobridge: <b​ylaws> It does for adreno, just needs someone who cares enough
11:49 ity: Re: "we don't have any kind of documentation for it": Wasn't the graphics also undocumented? Based on the docs, it was figured out by observing the prop driver, so I am really not sure I follow here
12:05 fdobridge: <a​irlied> NVIDIA has no plans to upstream their current driver and upstream has no interest in taking it
12:47 fdobridge: <S​id> so nvidia lied to me, hm https://developer.nvidia.com/blog/nvidia-releases-open-source-gpu-kernel-modules/
12:47 fdobridge: <S​id> see the Upstream approach sub heading
12:47 fdobridge: <S​id> though, it's possible that changed
12:57 fdobridge: <g​fxstrand> Yeah, what was always a "haha, nice thought"
13:05 fdobridge: <S​id> I see
13:06 fdobridge: <k​arolherbst🐧🦀> Sadly, I won't be able to say more about that "There are plans to work on an upstream approach with the Linux kernel community and partners such as Canonical, Red Hat, and SUSE. " part 🥲
13:06 fdobridge: <S​id> hm
13:07 fdobridge: <k​arolherbst🐧🦀> yeah.. it was about something else anyway
13:07 fdobridge: <S​id> oh well
13:07 fdobridge: <S​id> long live nouveau!
13:07 fdobridge: <S​id> viva la nouveau!
13:08 fdobridge: <m​agic_rb.> Then id ask why open it in the first place
13:08 fdobridge: <k​arolherbst🐧🦀> there will be a new driver anyway, and if nvidia wants to contribute or not is entirely up to them
13:08 fdobridge: <k​arolherbst🐧🦀> license
13:08 fdobridge: <S​id> nouveau is a silly name
13:08 fdobridge: <k​arolherbst🐧🦀> nvidia ran into the issue several times where things they wanted to use were gated by being GPL
13:08 fdobridge: <S​id> ah, ok, viva la nova!
13:08 fdobridge: <S​id> hehe
13:09 fdobridge: <k​arolherbst🐧🦀> so an open source driver allows them to use GPL only symbols in the kenrel
13:10 fdobridge: <k​arolherbst🐧🦀> however, there is also the policy inside linux that every interface needs an in-tree user
13:10 fdobridge: <m​agic_rb.> Whats the driver licensed as? Cause this seems questionable licensing wise
13:10 fdobridge: <S​id> MIT/GPL
13:11 fdobridge: <S​id> openrm, that is
13:33 fdobridge: <!​DodoNVK (she) 🇱🇹> It confuses translators
13:33 fdobridge: <S​id> it's also
13:33 fdobridge: <S​id> very redundant
13:33 fdobridge: <S​id> nuwu pronounces the same
13:34 fdobridge: <S​id> almost
19:12 fdobridge: <a​irlied> That statement explicitly says the current driver isn't suitable for upstreaming
19:18 fdobridge: <m​ohamexiety> yeah. I heard some enterprise features are locked behind the open driver only though so it's interesting. I wonder if eventually they'll drop the closed one in favor of it
19:21 fdobridge: <a​irlied> That is the plan
19:23 fdobridge: <a​irlied> But no idea how many years it will take
19:24 fdobridge: <t​om3026> with the current rate of things going into it, 42
19:24 fdobridge: <a​irlied> Like they would have to deprecate pre turing
19:25 fdobridge: <m​agic_rb.> ooor just allow the redistribution of the firmware :) but probably not happing
19:25 fdobridge: <m​agic_rb.> ooor just allow the redistribution of the firmware :) but probably not happening (edited)
19:25 fdobridge: <m​agic_rb.> ooor just allow the redistribution of the firmware :) but probably not happening (very different code path but still) (edited)
19:34 fdobridge: <a​irlied> Pre turing the fw and driver have secrets
19:35 fdobridge: <a​irlied> So redistribution of fw doesn't help them, it's one of the reasons they designed gsp
19:39 fdobridge: <m​agic_rb.> the driver wouldnt have to necessarily? nouveau can run without them so technically it should be possible to hook the open driver onto the old firmware
19:43 fdobridge: <a​irlied> The secrets might be in the fw api
19:44 fdobridge: <a​irlied> Also not sure why it keeps coming up in here, it's been repeated enough times. It's not going to happen
19:45 fdobridge: <m​agic_rb.> apologies, i havent read the older discussions
19:45 fdobridge: <m​agic_rb.> still quite new
19:52 fdobridge: <e​sdrastarsis> Following the pattern, maybe after driver 670 (kepler was deprecated in 470 and maxwell will probably be obsolete in the 570 driver)