7 ms·

> Though as reported previously, much of the AMDGPU driver code base is so large because of auto-generated header files for GPU registers, etc. In fact, 1.79 mi

> Though as reported previously, much of the AMDGPU driver code base is so large because of auto-generated header files for GPU registers, etc. In fact, 1.79 million lines as of Linux 5.9 for AMDGPU is simply header files that are predominantly auto-generated. It's 366k lines of the 2.71 million lines of code that is actual C code.

spullara 6y ago
Why not generate it during the build? Is there a good reason not to do that?
- stefan_ 6y ago
  The Linux kernel doesn't play the Firefox game of requiring Ruby, Python3, Python2, NodeJS and Rust to even be able to build the thing.
  - nathell 6y ago
    Not for the build itself, but there are Perl and Python scripts in the kernel source, which are referenced by the kernel's main Makefile.
  - Ar-Curunir 6y ago
    If you don’t want to use languages that enable code reuse, then you can’t complain about repeated code
- barumi 6y ago
  > Why not generate it during the build? If those headers aren't expected to change then, with regards to accountability, it's far better to have the code checked into the version control and processed as is. More importantly, if the code is already generated then there's no need to make the build system more brittle by adding a non-standard build target that depends on custom/third-party tools.
- ploxiln 6y ago
  It was generated by the hardware division. These are the registers that are authorized for disclosure in the open-source driver by the AMD employed open-source driver developers. So, it includes many times more register definitions than are ever used (consider there are 8x more register definition lines than actual code lines that could use them) and it includes many sets of 16 or 64 definitions that a software developer would have made one parameterized definition (all the same except for _00, _01, _02, _03, etc). But this is exactly what the hardware guys generated for public release, and it is to be used as-is. IMHO it's kinda annoying and sad. The rest of the kernel is held to a higher standard, that's why all the other non-trivial multi-arch multi-family multi-generation code in the linux kernel is much more concise / less sloppy. It takes a lot of effort to make it that way, and commercial companies pretty much never bother, except when required by the Linux maintainers. But, modern graphics drivers are way too complex and way too much work, and most people do want some proper modern GPU support in the kernel, so compromises have to be made. It's not too bad, just a bunch of inert header lines, git and the compiler handle them just fine I guess.
  - gridlockd 6y ago
    > It was generated by the hardware division. These are the registers that are authorized for disclosure in the open-source driver by the AMD employed open-source driver developers. ...which is arguably not compatible with the GPL: "The source code for a work means the preferred form of the work for making modifications to it."
    - tom_ 6y ago
      What modifications would you make that might be useful? The (proprietary) hardware isn't going to change.
      - dmurray 6y ago
        Remove some bugs, or improve its performance. Hardware drivers get updated all the time even when the hardware remains the same. I'm not an open-source absolutist: I think the pragmatic solution Linux went with is good here. But it's silly to suggest that the driver couldn't be improved if it were more open.
- Taniwha 6y ago
  >Why not generate it during the build? Is there a good reason not to do that? In many hardware shops the C definitions for the visible registers are generated automatically from the hardware's source code
  - symlinkk 6y ago
    Wait hardware has source code? I’m just a web dev so I’m not aware of this. What does the code look like?
    - pwg 6y ago
      Yes, there is "source code" for describing hardware. Here are two you can take a look at: VHDL: https://en.wikipedia.org/wiki/Vhdl https://en.wikipedia.org/wiki/Vhdl Verilog: https://en.wikipedia.org/wiki/Verilog https://en.wikipedia.org/wiki/Verilog
    - Taniwha 6y ago
      Depends on what you're building, boards tend to be done as net lists (essentially a list of components and wires and how they are connected) - but digital chips of more more than a few dozen gates are normally written in a highlevel language (linked to by other posters here) which can be compiled into both machine code that can be simulated, and synthesised into gates and wires (a net list) that can be laid out onto a chip
    - aasasd 6y ago
      I'll tell you more, hardware is often simulated in software from those source descriptions before going to any sort of production. Which is probably one of the reasons for the existence of these definition languages.
  - Taniwha 6y ago
    and I should add ... chances are the linux kernel is not the primary user of these addresses, more likely it's the internal DV ('Design Verification' - hardware QA/testing) teams who need access to all those internal debug/setup/etc registers that are not normally architecturally visible to the downstream software teams (like Linux/etc)
- saxonww 6y ago
  If it never changes, generating the headers during the build is just wasted time for whoever/whatever is running that build.

spullara 6y ago

Why not generate it during the build? Is there a good reason not to do that?

stefan_ 6y ago
The Linux kernel doesn't play the Firefox game of requiring Ruby, Python3, Python2, NodeJS and Rust to even be able to build the thing.
- nathell 6y ago
  Not for the build itself, but there are Perl and Python scripts in the kernel source, which are referenced by the kernel's main Makefile.
- Ar-Curunir 6y ago
  If you don’t want to use languages that enable code reuse, then you can’t complain about repeated code
barumi 6y ago
> Why not generate it during the build? If those headers aren't expected to change then, with regards to accountability, it's far better to have the code checked into the version control and processed as is. More importantly, if the code is already generated then there's no need to make the build system more brittle by adding a non-standard build target that depends on custom/third-party tools.
ploxiln 6y ago
It was generated by the hardware division. These are the registers that are authorized for disclosure in the open-source driver by the AMD employed open-source driver developers. So, it includes many times more register definitions than are ever used (consider there are 8x more register definition lines than actual code lines that could use them) and it includes many sets of 16 or 64 definitions that a software developer would have made one parameterized definition (all the same except for _00, _01, _02, _03, etc). But this is exactly what the hardware guys generated for public release, and it is to be used as-is. IMHO it's kinda annoying and sad. The rest of the kernel is held to a higher standard, that's why all the other non-trivial multi-arch multi-family multi-generation code in the linux kernel is much more concise / less sloppy. It takes a lot of effort to make it that way, and commercial companies pretty much never bother, except when required by the Linux maintainers. But, modern graphics drivers are way too complex and way too much work, and most people do want some proper modern GPU support in the kernel, so compromises have to be made. It's not too bad, just a bunch of inert header lines, git and the compiler handle them just fine I guess.
- gridlockd 6y ago
  > It was generated by the hardware division. These are the registers that are authorized for disclosure in the open-source driver by the AMD employed open-source driver developers. ...which is arguably not compatible with the GPL: "The source code for a work means the preferred form of the work for making modifications to it."
  - tom_ 6y ago
    What modifications would you make that might be useful? The (proprietary) hardware isn't going to change.
    - dmurray 6y ago
      Remove some bugs, or improve its performance. Hardware drivers get updated all the time even when the hardware remains the same. I'm not an open-source absolutist: I think the pragmatic solution Linux went with is good here. But it's silly to suggest that the driver couldn't be improved if it were more open.
Taniwha 6y ago
>Why not generate it during the build? Is there a good reason not to do that? In many hardware shops the C definitions for the visible registers are generated automatically from the hardware's source code
- symlinkk 6y ago
  Wait hardware has source code? I’m just a web dev so I’m not aware of this. What does the code look like?
  - pwg 6y ago
    Yes, there is "source code" for describing hardware. Here are two you can take a look at: VHDL: https://en.wikipedia.org/wiki/Vhdl https://en.wikipedia.org/wiki/Vhdl Verilog: https://en.wikipedia.org/wiki/Verilog https://en.wikipedia.org/wiki/Verilog
  - Taniwha 6y ago
    Depends on what you're building, boards tend to be done as net lists (essentially a list of components and wires and how they are connected) - but digital chips of more more than a few dozen gates are normally written in a highlevel language (linked to by other posters here) which can be compiled into both machine code that can be simulated, and synthesised into gates and wires (a net list) that can be laid out onto a chip
  - aasasd 6y ago
    I'll tell you more, hardware is often simulated in software from those source descriptions before going to any sort of production. Which is probably one of the reasons for the existence of these definition languages.
- Taniwha 6y ago
  and I should add ... chances are the linux kernel is not the primary user of these addresses, more likely it's the internal DV ('Design Verification' - hardware QA/testing) teams who need access to all those internal debug/setup/etc registers that are not normally architecturally visible to the downstream software teams (like Linux/etc)
saxonww 6y ago
If it never changes, generating the headers during the build is just wasted time for whoever/whatever is running that build.