Nvidia publishes 73k lines of 3D header files for Fermi through Ampere GPUs
phoronix.com
phoronix.com
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?
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.
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).
[1] https://github.com/devkitPro/deko3d/blob/master/source/maxwe...
Specifically curious if this inherently would "let the cat out of the bag" about the specifics of their chip design, for example.
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.
[1] https://developer.amd.com/wp-content/resources/RDNA2_Shader_...
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.
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.
Firmware is the enemy.
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."
My country doesn't have DMCA.
Out of curiosity, what are the ways you're talking about?
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?
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.
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.
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.
The write up in question was
https://hexkyz.blogspot.com/2021/11/je-ne-sais-quoi-falcons-...
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.
Thanks for the read.
https://nvidia.github.io/open-gpu-doc/
More specifically, I guess these are the new release:
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).
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!
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’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.
The FSF does not care about proprietary firmware, provided that the firmware “installation is not intended after the user obtains the product.”
https://ryf.fsf.org/about/criteria
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?
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.
I think a lot of folks are hoping to fix bugs in the Linux implementations for things like power scaling.
In cases like CUDA or OGL, it seems that the the kernel compilers are part of the driver package, which further confuses the discussion.
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).
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!
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.
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.
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.