4 ms·

If you're not intimately familiar with GPU drivers and what goes on this gives you a very quick, back-of-the-envelope of the size and complexity of the work inv

by harry8 3y ago

If you're not intimately familiar with GPU drivers and what goes on this gives you a very quick, back-of-the-envelope of the size and complexity of the work involved. 1/7th the size and complexity of the kernel for this one driver. I raised an eyebrow but I have only the vaguest notion of how the hardware works and what a driver might have to manage.

dralley 3y ago
As the article pointed out, the vast majority of the lines of code in the driver are autogenerated header files for things like defining hardware registers. There's not much complexity or logic in that type of code. Probably if AMD wanted to spend the time, they could compress it down to a fraction of it's current size.
- jmole 3y ago
  Right, if you have 7 different architectures, each with it's own register map, and then model-specific tweaks, you're going to have a ton of code like that.
  - undersuit 3y ago
    We could just compile it into a proprietary blob like Nvidia! /s
  - benlwalker 3y ago
    Is it really that much code? I don't know GPU hardware, but the NVMe spec header file in SPDK is around 4k lines[0]. If there's 7 of them and they're twice as complicated each, we're still well under 100k from register map headers. I didn't actually look through Linux to see how big they are, so maybe it is that much more complex. 0: https://github.com/spdk/spdk/blob/master/include/spdk/nvme_spec.h https://github.com/spdk/spdk/blob/master/include/spdk/nvme_s...
    - StillBored 3y ago
      NVMe is largely the model people here are complaining about. A small kernel shim driver that is talking to a huge firmware code base on the other side of a mailbox interface. Even on small m.2 style standalone drives, your looking at code, which not only handles the details of managing flash error correction, wear leveling, garbage collection, etc, etc, but all the code required to manage the thermal, voltage, pcie link training, etc of the 2-5 or so microcontrollers embedded in the drive and possibly an RTOS or two hosting it all. Never mind fabric attach (DPU?) NVMe devices which do all that, plus deal with thin provisioning, partitioning, deduplication, device sharing, replication, RAID, etc, etc. Frequently themselves embedding a Linux (or similar level of complexity OS) kernel in the control plane.
  - scns 3y ago
    > if you have 7 different architectures GPU or CPU? If talking about the latter only two [four] should count (ARM & x86 [+ [* 2 64BitVersion]]. If you meant the former forget my comment.
  - userbinator 3y ago
    Do they modify where all the registers are and the meaning of their bits with each new generation? That seems like an extremely wasteful way to do things. I'm not familiar with AMD's GPUs, but have done some "bare metal" Intel GPU programming, and there's definitely a lot of commonality between different generations going all the way back to the i810.
tester756 3y ago
>If you're not intimately familiar with GPU drivers and what goes on this gives you a very quick, back-of-the-envelope of the size and complexity of the work involved. 1/7th the size and complexity of the kernel for this one driver. ehh, no. almost all of this are header files >Meanwhile the open-source NVIDIA "Nouveau" driver is around 201k (21.7k blank lines, 24.3k lines of comments, and 155k lines of code). Or the Intel i915 DRM kernel graphics driver is around 381k lines via the same cloc judgment. so it seems like GPU driver is around 1% of kernel's code and you start thinking why actually kernel has this much code if GPU (out of all software) needs just around 1%.
- boppo1 3y ago
  Nouveau barely works iirc
  - smashed 3y ago
    That is a bit harsh.. Nouveau will bring up you're Linux desktop just fine and connect all your monitors. It will run OpenGL apps and light games. Last time I checked it could not boost the clock and push most chips to high performance mode. This is mostly 100% Nvidia's fault of not opening up the specs. Otherwise what nouveau has been able to reverse engineer is just amazing. The nouveau driver is so much less painful to use, it just works completely seamlessly. If you don't need the extra performance, it is not worth the trouble to install the Nvidia blob.
    - torginus 3y ago
      Unfortunately I had very negative experience with it. I have a laptop with an Nvidia secondary, GPU and had the repeat terrible experience of my computer locking up right on boot due to the broken Nouveau driver that shipped with the kernel. It'd have been fine to not even initialize the GPU, as I wasn't actually using it, which is what I ended up doing, disabling nouveau right from the Grub menu.
- nvm0n2 3y ago
  The NVIDIA proprietary driver is about the same size compiled as the Linux kernel, iirc. The reason is, GPU drivers are basically complete operating systems, just for the secondary computer we call the GPU instead of the CPU.

by harry8 3y ago

dralley 3y ago

As the article pointed out, the vast majority of the lines of code in the driver are autogenerated header files for things like defining hardware registers. There's not much complexity or logic in that type of code. Probably if AMD wanted to spend the time, they could compress it down to a fraction of it's current size.

jmole 3y ago
Right, if you have 7 different architectures, each with it's own register map, and then model-specific tweaks, you're going to have a ton of code like that.
- undersuit 3y ago
  We could just compile it into a proprietary blob like Nvidia! /s
- benlwalker 3y ago
  Is it really that much code? I don't know GPU hardware, but the NVMe spec header file in SPDK is around 4k lines[0]. If there's 7 of them and they're twice as complicated each, we're still well under 100k from register map headers. I didn't actually look through Linux to see how big they are, so maybe it is that much more complex. 0: https://github.com/spdk/spdk/blob/master/include/spdk/nvme_spec.h https://github.com/spdk/spdk/blob/master/include/spdk/nvme_s...
  - StillBored 3y ago
    NVMe is largely the model people here are complaining about. A small kernel shim driver that is talking to a huge firmware code base on the other side of a mailbox interface. Even on small m.2 style standalone drives, your looking at code, which not only handles the details of managing flash error correction, wear leveling, garbage collection, etc, etc, but all the code required to manage the thermal, voltage, pcie link training, etc of the 2-5 or so microcontrollers embedded in the drive and possibly an RTOS or two hosting it all. Never mind fabric attach (DPU?) NVMe devices which do all that, plus deal with thin provisioning, partitioning, deduplication, device sharing, replication, RAID, etc, etc. Frequently themselves embedding a Linux (or similar level of complexity OS) kernel in the control plane.
- scns 3y ago
  > if you have 7 different architectures GPU or CPU? If talking about the latter only two [four] should count (ARM & x86 [+ [* 2 64BitVersion]]. If you meant the former forget my comment.
- userbinator 3y ago
  Do they modify where all the registers are and the meaning of their bits with each new generation? That seems like an extremely wasteful way to do things. I'm not familiar with AMD's GPUs, but have done some "bare metal" Intel GPU programming, and there's definitely a lot of commonality between different generations going all the way back to the i810.

tester756 3y ago

>If you're not intimately familiar with GPU drivers and what goes on this gives you a very quick, back-of-the-envelope of the size and complexity of the work involved. 1/7th the size and complexity of the kernel for this one driver. ehh, no. almost all of this are header files >Meanwhile the open-source NVIDIA "Nouveau" driver is around 201k (21.7k blank lines, 24.3k lines of comments, and 155k lines of code). Or the Intel i915 DRM kernel graphics driver is around 381k lines via the same cloc judgment. so it seems like GPU driver is around 1% of kernel's code and you start thinking why actually kernel has this much code if GPU (out of all software) needs just around 1%.

boppo1 3y ago
Nouveau barely works iirc
- smashed 3y ago
  That is a bit harsh.. Nouveau will bring up you're Linux desktop just fine and connect all your monitors. It will run OpenGL apps and light games. Last time I checked it could not boost the clock and push most chips to high performance mode. This is mostly 100% Nvidia's fault of not opening up the specs. Otherwise what nouveau has been able to reverse engineer is just amazing. The nouveau driver is so much less painful to use, it just works completely seamlessly. If you don't need the extra performance, it is not worth the trouble to install the Nvidia blob.
  - torginus 3y ago
    Unfortunately I had very negative experience with it. I have a laptop with an Nvidia secondary, GPU and had the repeat terrible experience of my computer locking up right on boot due to the broken Nouveau driver that shipped with the kernel. It'd have been fine to not even initialize the GPU, as I wasn't actually using it, which is what I ended up doing, disabling nouveau right from the Grub menu.
nvm0n2 3y ago
The NVIDIA proprietary driver is about the same size compiled as the Linux kernel, iirc. The reason is, GPU drivers are basically complete operating systems, just for the secondary computer we call the GPU instead of the CPU.