A stable ABI (at least for GSP FW)

[edisionnano]

During the Linux Plumbers Conference 2022 the Nouveau devs held a presentation which mostly concerned the future of the project after NVIDIA released this open source kernel drivers which reignited the interest in Nouveau project.
One of their most important concerns is the lack of a stable ABI. What this means is that NVIDIA drivers are version locked. For example, the latest kernel module is version 515.49.15 and only userspace libraries and GSP firmware version 515.49.15 is compatible with it. Nouveau is an upstream driver and you can see why this is an issue.
I'd like to request a better design with a stable ABI
https://youtube.com/watch?v=KkOdMwZRpYY at 08:49:20

[mtijanic]

Hey there. Yes, lack of stable ABI is a known problem with getting an upstream GSP driver - whether Nouveau or a new one. We have been thinking about this for a long time and the infrastructural groundwork is mostly in place.
If you look at some of the APIs for talking to GSP, such as this file you'll see that the C code is generated from a higher level Interface Definition Language. Longer term, we will generate API+ABI-stable messages - this could look similar to e.g. protobuf messages with optional fields.

The major issue here is that once we start supporting a stable, versioned ABI, we need to carry all the additional baggage for a long time. And GSP development is still moving very rapidly - just this week we've updated at least 3 RPCs (that I know of). If this was all versioned we'd accumulate so much tech debt before we ever shipped a production ready geforce driver.

Bottom line is, we are aware of the issues this causes for third party kernel drivers, and we do have plans on how to resolve it, we just can't execute on those plans yet or everyone will be paying the price for a long time to come. Fortunately, this shouldn't preclude the development of such drivers - yes there will be a bit of throwaway work, but getting the r515 GSP image booting is 98% of the work, and then switching it use a versioned interface later should not be much of an issue.

[edisionnano]

I don't think the GSP not being open matters much. Ofc it would be nice if it was but it doesn't matter much. AMD also has blob fw. What matters is that this FW is distributed under a license that permits redistribution.

[throwaway1037]

It is a mistake to treat software respecting our freedom as a mere nice-to-have feature instead of a moral imperative, yet this is exactly what the rhetoric of "open source" invites us to do.
See https://gnu.org/philosophy/open-source-misses-the-point.html

What matters is our freedom, and all free software licenses permit redistribution, which also meets your criteria.
The GSP firmware being free/libre matters a lot, because without it, these drivers are unusable in the free world.

AMD publishing firmware blobs is no excuse for anyone else to do so.
Two wrongs don't make a right.

[mtijanic]

do the bosses who make the decisions to release this code under a free software license know about this situation and realise the issues people have raised?

I can't really say if a particular "boss" is aware of a particular issue, but generally the consequences of not publishing the firmware sources (and signing keys) are well known. This forum is monitored by people who aggregate user feedback, so you have definitely been heard. I'm afraid we can't know if it made it into the "Top N" executive summary or if it was pushed out by other user feedback that was prioritized higher.

Either way, the end result is the same: There are currently no plans to publish the firmware sources. We are aware that as a consequence NVIDIA GPUs are not usable by projects such as linux-libre. We have no plans to change this.

Annoying as it may be, there is not really much more you can do about this. You are free to preach your philosophy and try to build a critical mass of users for whom this is a showstopper issue; it could work. However I have to ask you to refrain from derailing unrelated discussions with these topics and stick to the several already open threads.

I don't think there's anything else for us to say on this subject for the time being. Thank you.

[throwaway1037]

@mtijanic thank you for talking with me. I understand you're doing all you can, I just wish NVIDIA would take action. Many of these technical issues stem from the lack of freedom, and if all the components were libre, people wouldn't have to be so reliant on asking tons of questions and speculating. We want to cooperate with you, NVIDIA.

[throwaway1037]

It's possible NVIDIA wrote those blobs in binary, maybe if they were masochists, but it's much more likely they wrote them in a human-readable programming language, such as C or one of the various assembly languages.
Disassembling precompiled binaries is a form of reverse-engineering and is not source code.
Source code contains things like macros, comments, functions, and many other constructs designed to make programs human-readable.

@mtijanic please can you confirm for @ValZapod that these blobs do have source code?
I don't think he will believe me unless he hears it straight from the people working on them, and he keeps bringing it up.

[edisionnano]

@mtijanic Nouveau aims to support all Nvidia gpus (particularly Kepler and newer). From what I understand GSP fw isn't driver code moved to fw but rather all firmwares merged into a single package. While some firmwares are provided by nvidia over at linux firmware, pmu is notably missing and it does indeed matter for reclocking maxwell and pascal using Nouveau so along with stable GSP I really hope we'll see the other firmwares published too

[mtijanic]

Do you know why these features were omitted in the initial release?

The removed code is currently not functional when GSP is in use. It is present as dead, non-functional code in the proprietary driver running in GSP mode. It was removed from the published source because:

1. It would just be confusing to everyone to publish useless dead code.
2. Every line of code we publish has to be read and approved. No point in doing that for stuff that doesn't work and will be rewritten anyway.

We are bringing up features with GSP as we go along. For example, the initial datacenter-only closed source release of the GSP model was mid 2021 with 470.xx drivers and it did not have display capabilities at all.

[edisionnano]

Interesting, so lower CPU usage too. I believe a discussion/issue should be created here with the differences between prop and open

[throwaway1037]

This doesn't seem to add up.
Why partially liberate a crippled driver with missing functionality that depends on a 30+mb blob instead of the previous driver that had all this functionality, supported older generations, and didn't need to use the GSP?
This seems to corroborate the theory that NVIDIA moved all the interesting code into the firmware blob, refused to liberate it, and then released "open" modules as a way of getting good publicity and being competitive in data centers, whilst not providing much help to Nouveau.

@mtijanic please tell me I'm wrong.
I remember in another thread you said that the GSP blob is an aggergation of many smaller blobs that were previously embedded in other files, but if this is the case, then why also remove all the now-dead code that would be useful to Nouveau and previous gens?
NVIDIA certainly has the resources to approve that code for publication.

[aaronp24]

@throwaway1037, edisionnano opened this thread to discuss a stable API for the GSP firmware. Can you please refrain from derailing this and other threads? Milos already asked you nicely once.

[throwaway1037]

@aaronp24 perhaps I was being unclear earlier.
My point is that the issue of the blobs being proprietary is the root cause of many technical issues, so if the blobs are released as free/libre software, those technical issues would become fixable.
At the moment, we are reliant on NVIDIA to fix these issues like ABI stability for us, but if they were free/libre software, we could fix them ourselves.

Therefore, the issue of freedom is relevant to every technical issue on this tracker, and not having freedom is actively making fixing problems a nightmare.
Currently, people have to report an issue and then wait on NVIDIA to fix it, because the blobs are proprietary and half of the non-GSP code is unpublished, so we don't have a copy of that source code to work on fixing.

If you also take into account that the previous non-GSP driver was superior to this driver in terms of GPU support, and had many more fully-implemented features, then it becomes obvious to ask why this half-finished, blob-dependent driver was partially released as free/libre software (blobs aside) when the previous driver would have been much more useful to the community.

Those are my thoughts: I am discussing the relevant technical issue, but I recognise that the root cause is a lack of freedom, and that many of these technical issues wouldn't even exist if we had a free/libre copy of the previous, non-GSP driver.

I hope this makes sense, please ask me to clarify if I was unclear.