Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • bridgman
    replied
    Originally posted by DanT View Post
    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).

    Leave a comment:


  • ResponseWriter
    replied
    Originally posted by er888kh View Post
    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.

    Originally posted by Michael View Post

    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.

    Leave a comment:


  • cb88
    replied
    Originally posted by intelfx View Post

    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.

    Leave a comment:


  • GreenReaper
    replied
    Originally posted by intelfx View Post
    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?

    Leave a comment:


  • marios
    replied
    Originally posted by V1tol View Post

    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?

    Leave a comment:


  • intelfx
    replied
    Originally posted by Developer12 View Post
    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.
    Last edited by intelfx; 12 May 2022, 02:42 PM.

    Leave a comment:


  • Developer12
    replied
    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.

    Leave a comment:


  • smitty3268
    replied
    Originally posted by Michael View Post

    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.

    Leave a comment:


  • V1tol
    replied
    Originally posted by blackshard View Post
    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.

    Leave a comment:


  • Michael
    replied
    Originally posted by blackshard View Post
    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.

    Leave a comment:

Working...
X