6 ms·

Nvidia publishes 73k lines of 3D header files for Fermi through Ampere GPUs

186 points by pantalaimon 4y ago

digdugdirk 4y ago
Can someone knowledgeable about the space please help me understand why this is important? 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) 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?
- monocasa 4y ago
  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.
- stevehawk 4y ago
  basically they just published a large amount of API for developers to use
- jpollock 4y ago
  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.
  - averne_ 4y ago
    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). [1] https://github.com/devkitPro/deko3d/blob/master/source/maxwell/engine_3d.def https://github.com/devkitPro/deko3d/blob/master/source/maxwe...
    - digdugdirk 4y ago
      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.
      - averne_ 4y ago
        > 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. [1] https://developer.amd.com/wp-content/resources/RDNA2_Shader_ISA_November2020.pdf https://developer.amd.com/wp-content/resources/RDNA2_Shader_...
- deleted 4y ago
  [deleted]
pavlov 4y ago
The headers are here in HTML-navigatable form: https://nvidia.github.io/open-gpu-doc/ https://nvidia.github.io/open-gpu-doc/ More specifically, I guess these are the new release: https://nvidia.github.io/open-gpu-doc/classes/3d/ https://nvidia.github.io/open-gpu-doc/classes/3d/
School-Cotton 4y ago
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!
- tendstofortytwo 4y ago
  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.
  - paulmd 4y ago
    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!
    - kadoban 4y ago
      > 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.
garyware1299 4y ago
[flagged]
sylware 4y ago
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).

186 points by pantalaimon 4y ago

Can someone knowledgeable about the space please help me understand why this is important? 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) 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?

monocasa 4y ago
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.
stevehawk 4y ago
basically they just published a large amount of API for developers to use
jpollock 4y ago
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.
- averne_ 4y ago
  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). [1] https://github.com/devkitPro/deko3d/blob/master/source/maxwell/engine_3d.def https://github.com/devkitPro/deko3d/blob/master/source/maxwe...
  - digdugdirk 4y ago
    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.
    - averne_ 4y ago
      > 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. [1] https://developer.amd.com/wp-content/resources/RDNA2_Shader_ISA_November2020.pdf https://developer.amd.com/wp-content/resources/RDNA2_Shader_...
deleted 4y ago
[deleted]

pavlov 4y ago

The headers are here in HTML-navigatable form: https://nvidia.github.io/open-gpu-doc/ https://nvidia.github.io/open-gpu-doc/ More specifically, I guess these are the new release: https://nvidia.github.io/open-gpu-doc/classes/3d/ https://nvidia.github.io/open-gpu-doc/classes/3d/

School-Cotton 4y ago

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!

tendstofortytwo 4y ago
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.
- paulmd 4y ago
  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!
  - kadoban 4y ago
    > 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.

garyware1299 4y ago

[flagged]

sylware 4y ago

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).