AMD Graphics Driver Surpassing 4 Million Lines Of Code In Linux 5.19, NVIDIA Opens Up At 1 Million

[bridgman]

It would be more informative to present the number of C lines not counting the headers.
Not sure I am reading it correctly, but it is 476k for AMD and 742k for NVidia?

If you break it down by subfolders you get a better picture:

include (register headers) - 2730 KSLOC
amdgpu - 175 KSLOC
amdkfd - 26 KSLOC
display - 248 KSLOC
pm - 114 KSLOC

Breaking down this way counts function prototypes as code, but register headers as "headers". I'm on the fence re: whether function prototypes should be counted as code, since they don't really add to complexity or influence maintainability. Anyways, counting them as code (ie worst case) we get 563K lines of code and 2730K lines of headers.

This ignores blank and comment lines, since hopefully they improve rather than reduce maintainability

This is based on the tips of Linus's kernel tree, ie not including latest additions, with a total of around 3827 KSLOC including blanks and comments (doing the math in my head).

[ResponseWriter]

*It's already in the testing repository

Oh, that's a good start! At least those with Nvidia cards can start testing, although personally I'll be sticking with AMD until at least next year.

It would be very surprising if it's mainlined even this year at all.... The API/ABI isn't yet stable, no Mesa clients using the kernel driver yet, etc.... Lots of work ahead. At least a few kernel cycles before it would likely be stable enough for mainline.

That's what I was expecting considering how long it took AMD's stuff to get into mainline. I'm in no rush to buy Nvidia GPUs anyway but good to know at least the kernel side will be better supported if I ever do.

[cb88]

It's certainly in their right to split functionality between the device (firmware) and the host (driver) as they see fit. Open-sourcing the host side resolves most practical concerns (maintainability and security) regardless of the split.

Except it doesn't because its exactly the same situation as before... a binary blob is tainting your system, sure it isn't tainting the kernel directly now but that's moot as PCIe devices have unfettered access to the PCIe bus. So in effect you still have 30MB of unknown code running in your system.... this is a bit less of a concern for sane firmware but a 30MB blob is far and away from that.

[GreenReaper]

It's certainly in their right to split functionality between the device (firmware) and the host (driver) as they see fit. Open-sourcing the host side resolves most practical concerns (maintainability and security) regardless of the split.

If it's really 30MB of code, I doubt it's all secure. It might make it easier to fuzz and hence find issues in, though?

[marios]

It is great even in current state - just to have the ability to patch kernel side driver with some useful stuff, like ReBar on unsupported systems and build it with march=native and not use linked prebuilt blob.

ReBar on unsupported systems? Can you really rebar non Ampere gpus?

[intelfx]

Shame that there's no actual driver code in any of those 1M lines. It seems it's all been shoved down into 30+ MB of firmware.

It's certainly in their right to split functionality between the device (firmware) and the host (driver) as they see fit. Open-sourcing the host side resolves most practical concerns (maintainability and security) regardless of the split.

[Developer12]

Shame that there's no actual driver code in any of those 1M lines. It seems it's all been shoved down into 30+ MB of firmware.

[smitty3268]

From my communication with NVIDIA and given Red Hat's involvement,. Nouveau Mesa will likely gain support for using the new kernel driver and that addresses the upstreaming kernel driver requirements as long as the Nouveau Mesa code makes use of all the exposed interfaces.

It seems unlikely to ever go upstream while they are still just doing 1 git commit per release with everything dumped together. So I think there's still a lot of workflow issues that need to be done on NVidia's side before it makes sense to even begin discussing upstreaming.

[V1tol]

If the policy "no opensource userland = no mainlining for kernel driver" is still valid, that kernel driver won't ever be merged into mainline.
And the userland part won't be opensourced, as stated by NVIDIA FAQs, I guess this is just some help for nouveau guys.

It is great even in current state - just to have the ability to patch kernel side driver with some useful stuff, like ReBar on unsupported systems and build it with march=native and not use linked prebuilt blob.

[Michael]

If the policy "no opensource userland = no mainlining for kernel driver" is still valid, that kernel driver won't ever be merged into mainline.
And the userland part won't be opensourced, as stated by NVIDIA FAQs, I guess this is just some help for nouveau guys.

From my communication with NVIDIA and given Red Hat's involvement,. Nouveau Mesa will likely gain support for using the new kernel driver and that addresses the upstreaming kernel driver requirements as long as the Nouveau Mesa code makes use of all the exposed interfaces.