What do these 3d header files do, and why/how will this make life easier for "Nouveau"? Finally, why (aside from just open source being the best source) will this benefit people like myself who don't understand what just happened?
When looking at a binary blob for the driver, the person writing the docs of what the driver does sees "jump $addr1" but they don't know what's at the other end. To write the specification for the clean room reimplementation, they need to read the destination assembly and document that.
This provides documentation on what is at the other end of the address and what it does, and what the layout of each parameter is.
That means they will hopefully avoid having to recurse and understand all of the binary code to write the specification.
That's not exactly correct. This is register maps for the 3d engine (also called class), what you describe would be closer to the shader ISA.
In driver code you'll see them building command buffers that set registers in those classes to certain values. It could be the RGBA values of the clear color, or a virtual address in the GPU space.
This documents the names of these registers. This makes reverse engineering somewhat easier as you don't really have to guess anymore. But in most cases it was pretty clear from the start, and for some generations those were already well documented by open source efforts. One of best known gens is probably Maxwell since it was used in the Nintendo Switch, see for instance [1] (or code in yuzu/Ryujinx) which is the equivalent of those headers NV published.
However this isn't a very big step in documenting their GPUs. The exact functions of those registers aren't explained, but most importantly the shader ISA isn't documented at all, which is essential to build a good open-source driver.
Source: I have reverse engineered some driver code for Maxwell (and used similar headers to write drivers for nvdec and nvjpg).
You say this isn't a very big step - out of curiosity, how much work would have been involved in getting this release open sourced? And what might be preventing them from releasing the shader ISA?
Specifically curious if this inherently would "let the cat out of the bag" about the specifics of their chip design, for example.
> how much work would have been involved in getting this release open sourced
Close to no actual effort (the headers are autogenerated). However there was probably a lot of work behind the scenes with their legal team/whatever to clear the release.
About the shader ISA, I wish I knew. It's certain that the documentation exists, because they provide it to some developers (I've been told the Maxwell ISA docs are part of the Nintendo Switch SDK), so it's not like they have to write it from scratch.
And AMD provides full docs about it [1] (not sure about Intel), so I don't see how it could provide a significant edge over their competition. Maybe raytracing instructions? But for a motivated reverse engineer this stuff isn't impossible to figure out. I think it's down to company culture and inertia.
I don't know about Arc, but Intel has historically probably been the most open with their GPU docs. AMD's is (while laudable, particularly compared to Nvidia) unfortunately a bit of a autogenned dump without context. Where as Intel's is closer to what I expect out of decent SoC documentation; it'll be about half prose explaining the why(!!), and half the autogenned tables of registers and opcode formats.
AMD's approach seems to be documentation in the style you describe plus employed FOSS developers who get access to internal people, simulators, possibly even source code. Makes it annoying for externals to try to contribute code, but the drivers are good.
It isn't really, and doesn't really do squat for nouveau. Nouveau has been thwarted by the secretful FALCON units, and Nvidia's decision to lock power management and clock management behind high secure mode.
See, in order to make those calls, the command buffer is submitted along with a hash value, plus the firmware itself iirc. Been a while. That firmware is signed with a private key known only to Nvidia, and they don't sign third party firmware.
So nouveau can write all the firmware they want, but they can't actually get access to any functionality gated behind high-secure mode. There are ways*, but unfortunately all of them run afoul of the spirit of DMCA.
> There are ways, but unfortunately all of them run afoul of the spirit of DMCA.
This is not true. There is federal circuit precedent which invalidates the DMCA for exactly those cases
Chamberlain v. Skylink, final court of appeals for the federal circuit opinion, page 39:
"Underlying Chamberlain’s argument on appeal that it has not granted such authorization lies the necessary assumption that Chamberlain is entitled to prohibit legitimate purchasers of its embedded software from “accessing” the software by using it.
Such an entitlement,
however, would go far beyond the idea that the DMCA allows copyright owner to prohibit “fair uses . . . as well as foul.” Reimerdes, 111 F. Supp. 2d at 304.
Chamberlain’s proposed
construction would allow
copyright owners to prohibit exclusively fair uses even in the absence of any feared foul use.
It would therefore allow any copyright owner, through a
combination of contractual terms
and technological measures, to repeal the fair use doctrine with respect to an individual
copyrighted work—or even
selected copies of that copyrighted work. Again, this implication contradicts § 1201(c)(1) directly. Copyright law itself authorizes the public to make certain uses of copyrighted materials.
Consumers who purchase a product containing a copy of embedded software have the inherent legal right to use that copy of the software. What the law authorizes, Chamberlain cannot revoke."
The Americans decided that copywrite wasn't enough so implemented legislation to prevent reverse engineering bypassing IP for "security" reasons.
So they have this interesting little dance they have to do around reverse engineering on whether a software lock constitutes DRM that you are hacking and if that DRM is fit for purpose. Because terrible DRM that is trivial isn't actually DRM.
It gets complicated as a lot of it ends up being ultimately subjective.
In this scenario, is using firmware that you know has not been signed by Nvidia, on a system that you know shouldn't run it unless it has been signed breaking DRM? And is the firmware signing DRM?
DRM applies only to copyrighted works. The functional aspects of a GPU (what actually makes it work and enables you to use it) are not copyrighted, in the same way that a machine's mechanisms aren't (patents might still exist)
Wasn't Tivoisation about DRM preventing you from using a different Linux kernel.
I didn't think that DRM applied only to copywritten works. I don't mind being wrong, but if you could expand on what exactly was wrong and what is the actual situation as I am only saying what I understand to be the situation.
What I meant with DRM was "legallity of breaking it".
If a technological measure that controls access to hardware has no connection to copyright, there's no legal concern about litigation or bad precedent being set.
There was a lot of work done by the Switch hacking community, which uncovered some fatal cryptosystem flaws w.r.t. secretful FALCONs. It is apparently possible to leak the hash against which the secretful falcon compares against in the hardware from the High Security side of things to LS.
It's a fairly in-depth and tricky thing though. Basically you're having to do firmware reverse engineering and basically chaining together ROP gadgets to figure out what the FALCON expects to see to transition into HS mode, and then retrying/cleverly orchestrating things to make it happen.
I haven't had the bandwidth/life situation to really sit down and cobble together the requisite set of skills to make inroads on proving my hunch that one could use some of the methods described to front-run the HS signed firmware check with the right gadget. Heck, last note I have, I was still trying to figure out how to setup linux kernel code such that I could get a reasonably ergonomic "attempt load firmware blob, gracefully fail to try again" to get a decent test rig going for the experiment to at least make the requisite facechecking of my own ignorance required endurable until I could get a PoC sorted. If I could manage to do it, I guess I'd be in a decent position to hit up EFF and see if I can be a decent legal test case to see if I could squeak through in terms of the exception for reverse engineering something to restore it to it's previous functioning. (Older cards not having secretful shenanigans to deal with) or something. The legal nastiness is actually part of what has kept me from making much in the way of progress even though I really, really want to do it.
If my reading of supporting documentation is right though, it's technically possible, you just have to be really patient and not give up.
Also note, this would almost certainly attract legal attention, because it is HS mode that secures a bunch of the HDMI related DRM functions as well. As demonstrated in that write up, you can bubble out the hashes of keys burnt in in the manufacturing process. Just because you don't have DMCA to worry about, doesn't mean it won't rear it's head elsewhere. There's a lotta money at stake.
I don't care half so much about that the HDMI though as the power management and reclocking shenanigans; there was absolutely 0 reason to lock that behind HS mode other than Nvidia wanting to create vendor lock-in, and prevent users/non-Nvidia developers from being able to write their own firmware.
If you beat me to the experiment, go with the knowledge you're doing $deity's work, and good hunting.
Inside just about every Nvidia GPU there's a bunch of little engines they internally call classes. This documents the 3D graphics rendering engines' method calls (the commands in the physical GPU command list) and memory layout for instances of these classes.
GPUs are the most complex chips out there. Getting dumped on the head bazillions of registers won't do as a hardware programing manual. Saying otherwise is a sham.
If their hardware is less messy than amd one, this hardware programming manual should include:
1 - a host init part: upload the firmware files (I can feel the gaze of the open source zealots). Since those chips are the most complex ones, you need some software jingle room to "fix" bugs in the hardware programming interface. Then setup the command ring buffers (look at usb xhci and or amd hardware here). With huge pci "bars", you may be able to simplify some things here, and I think it is kind of done now, but I don't recall the marketing name.
2 - the full hardware programing manual of the 3D/compute pipeline, done via those very command ring buffers. That include the setup of gpu virtual address spaces for shaders (last time I check amd hardware had 16, namely don't run more that 16 GPU "tasks" at the same time...). That with full shader ISA documentation (amd doc an that matter is amazing, but the documentation on how the 3D pipeline uses this ISA is kind of shaby).
When Nvidia published their open-source GPU drivers, there was a huge amount of moaning by free software absolutists about how it didn't really count because they just moved a bunch of logic into the firmware, or weren't open-sourcing CUDA, or whatever. Nvidia folks always responded with "our open-source journey is just beginning, but stay tuned!"
I know Nvidia doesn't have a lot of goodwill in the open-source community, but it's good to see that steps in the right direction are continuing!
> there was a huge amount of moaning by free software absolutists
I'm kinda glad that happens, even though I don't participate and the pragmatist in me sometimes disagrees.
I am glad Stallman exists and maintains his ultra-absolutionist hard line. I respect hom greatly for that, and while I often roll my eyes at his intentional foot-gunning of his own use of technology, I also 100% believe he's done an order of magnitude more to improve society than the more pragmatic open source advocates like esr.
In my head, the opposite end of the bellcurve is companies like Oracle. And they're _way_ better funded and more politically powerful than Stallman or esr or the entire "open source" movement put together. Without "extreme fringe wing nut GPL virality advocating loudmouths", Larry Ellison will drag software philosophy "the middle ground" so far to his end that we will all lose out.
So big shoutouts from me to the free software absolutists, even if I don't join in on your chorus (or internet dogpiles). My personal software philosophy probably is grounded in my mid 90's Perl hacking, and I'm very much behind Larry Wall's GPL/Artistic dual license approach. (I do though have ongoing doubts in my head about whether or not the recent spate of "non-open source" licenses aimed at restricting the cloud hyper scalers from SaaS-ing your stuff without contributing anything at all. I respect what they're trying to do at Mongo and Redis. I'm not sure if it will (or even if it should) work.)
> I am glad Stallman exists and maintains his ultra-absolutionist hard line.
I’m glad too. Whenever I read some of his writings, I cannot stop the feeling that he had bee right all along, and had seen most of the current dystopia coming, something like almost 20-30 years before it happened.
So if you have a product that needs a ton of proprietary software to run, RMS will go berserk if you run that software on the CPU, but if you shift it to run on another processor in the product and make sure users can’t change it then all is good, have a RYF certification. This does not make sense. Maybe it made sense 30 years ago.
If you’re stallman, proprietary firmware isn’t bad so long as it’s suitably hidden so it can’t offend your sensibilities. So pretend CPU microcode updates don’t exist and add secondary processors to deal with blobs (purism). Does ensuring users cannot upgrade firmware make them more free?
I agree about the eye rolling absurdity there. But I also suspect stuff like the opening up of various bits of RaspberryPi firmware blobs wouldn’t have happened without people who share his philosophy there. Same with hardware (and software) like Bunnie Huangs Precursor, a piece of as close as practically fully upon source hardware, where the cpu is implemented as an open source FPGA, and the Xous OS for it is written ground up in Rust. That’s a hell of a complex project, and a fascinating , that in my opinion would probably never have been worth anyones time to even start on, if they didn’t share (and possibly exceed) some of Stallman’s philosophical absurdity.
Like I said, I acknowledge the “ extreme fringe wing nut GPL virality advocating loudmouths” and appreciate their existence, if only as a balance to the “make Larry Ellison infinitely rich and powerful” kind of alternatives.
CUDA is their moat and their drivers do add significant value, seemingly more than AMD. So it's reasonable to expect that these won't be open sourced any time soon. Honestly I'm surprised why people expect them to just open source core IP like this.
Personally, my threshold for when they're off the shit-list is when they release the userspace component open source, when they support GBM, and when they stop actively sabotaging Nouveau. Maybe they'll get there, but I'm not exactly holding my breath.
That doesn't mean what they've done so far is insignificant. Being able to run an untainted kernel will be nice (for those running new enough GPUs anyways).
eh I think it's reasonable to have assumed they would continue to hold the stance that they had been holding for years. I'm sure the absolutists you talk about would be happy to be proven wrong.
A lot of people just blindly argue the absolute most negative possible stance period with NVIDIA, that they will never ever do anything positive and any positive stuff that happens doesn't matter at all because of reasons that are invented on the fly.
they open the kernel side? not good enough, they still have blobs (so does AMD) and the userland is still closed (which, so are parts of AMD's as well - the raytracing stuff is all behind closed licenses for example). They added adaptive sync support? Well, why don't they open up g-sync native!? Oh, they did that too? ....
it's similar to the anti-apple set that are just going to shit all over apple regardless of what happens. Apple publishes an API to make Asahi linux's job easier? Not good enough! apple is evil guys!
it's just so tedious and childish, like haha guys did you hear that linus gave NVIDIA the finger? that makes me laugh out loud guys!
> lot of people just blindly argue the absolute most negative possible stance period with NVIDIA, that they will never ever do anything positive and any positive stuff that happens doesn't matter at all because of reasons that are invented on the fly.
I mean, it's been what, 30 years or so during which nvidia did nothing on this front until ~last year? How are you even judging absolutists vs not? There's been no small steps you could judge them by, right?
But ya, I'm _super_ pumped nvidia is heading in the right direction with this stuff, I hope they continue.
Nvidia's hostility to open source and Linux is well known. This is a company that signs code to prevent open source driver development. But now they want a piece of the sweet datacenter revenue, so they have to open up.
Calling a company that released native Linux drivers (even if they're not opensource) with full capabilities "hostile to Linux" is some massive obliviousness. They've been supporting their hardware on Linux as a platform for decades now which is more than almost all other manufacturers.
It's this dumbass hyperbole that really shows just how disconnected from reality a lot of OSS zealots are. Does having nVidia driver be closed source suck? Eyup. Is it "hostility towards Linux" on the levels of other manufacturers that don't even bother to bring up their hardware on the platform? Nope.
I've been buying Nvidia hardware to use with Linux since 2003 since pragmatically it works well but honestly their efforts towards open source are mediocre and unworthy of meaningful praise. While their are only 3 major players in this class its worst in class by a mile.
The combo of hardware/software if using open source drivers isn't worth buying or using. I don't think its at all meaningful to talk about progress until they at least offer something anyone ought to bother using.
I mean if I ordered a nice steak and you served me a literal shoe I wouldn't praise you for remembering to also bring steak sauce.
The article discusses this with regards to "Nouveau", which seems to be an open source Nvidia specific driver - https://en.wikipedia.org/wiki/Nouveau_(software)
What do these 3d header files do, and why/how will this make life easier for "Nouveau"? Finally, why (aside from just open source being the best source) will this benefit people like myself who don't understand what just happened?