Live data from Hacker News

AMD Open-Source GPU Kernel Driver Above 5M Lines, Entire Linux Kernel at 34.8M

phoronix.com

51–60 of 77 posts

Re: AMD Open-Source GPU Kernel Driver Above 5M Lines, Entire Linux Kernel at 34.8M

#51
post #25

Earlier quoted context omitted.

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.

>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…

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.

Re: AMD Open-Source GPU Kernel Driver Above 5M Lines, Entire Linux Kernel at 34.8M

#52

Earlier quoted context omitted.

There is no business reason to restrict themselves on the ISA, and it would be make their hardware less performant compared to the competition which would not be so bound.

The competition is very much bound to a rather narrow ISA which is why CUDA is forward and backwards compatible whilst ROCm isn’t. ROCm will be pointless until at least forward compatibility will be guaranteed by design.

CUDA is subsequently compiled to the hardware assembly at runtime isn't it? Like precompiled shaders.

C++ -> PTX -> Hardware ISA

Re: AMD Open-Source GPU Kernel Driver Above 5M Lines, Entire Linux Kernel at 34.8M

#53
Corporations don't incentivize good engineering, they incentivize functionality at any cost. This leads to giant codebases, over-engineering, bad engineering, fragility, unmaintainable, useless code, and duplication. The FOSS/FLOSS community must push back against the hot mess turds corporations want to dump into their source.

Re: AMD Open-Source GPU Kernel Driver Above 5M Lines, Entire Linux Kernel at 34.8M

#54
post #38
post #28

Earlier quoted context omitted.

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.

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.

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

Re: AMD Open-Source GPU Kernel Driver Above 5M Lines, Entire Linux Kernel at 34.8M

#55

Does a graphical representation of the files in the Linux kernel exist anywhere? Like a graphical file explorer but for the different kernel components.

Wikipedia has a graph showing high-level breakdown of the kernel tree, and the size of the components[1]

[1] https://en.wikipedia.org/wiki/Linux_kernel#/media/File:Sanke...

Re: AMD Open-Source GPU Kernel Driver Above 5M Lines, Entire Linux Kernel at 34.8M

#56
post #38
post #28

Earlier quoted context omitted.

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.

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.

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

Re: AMD Open-Source GPU Kernel Driver Above 5M Lines, Entire Linux Kernel at 34.8M

#57
Why are GPU drivers baked into the kernel?

Wouldn’t it be better to load them in such a way that a crash in the GPU driver can be recovered from as opposed to crashing the whole system?

Other operating systems load the GPUs drivers separately.

Re: AMD Open-Source GPU Kernel Driver Above 5M Lines, Entire Linux Kernel at 34.8M

#58
post #57

Why are GPU drivers baked into the kernel? Wouldn’t it be better to load them in such a way that a crash in the GPU driver can be recovered from as opposed to crashing the whole system? Other operating systems load the GPUs drivers separately.

Why should having the GPU drivers checked into the same repository mean that they can't be loaded and unloaded dynamically?

Re: AMD Open-Source GPU Kernel Driver Above 5M Lines, Entire Linux Kernel at 34.8M

#59
post #51

Earlier quoted context omitted.

>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…

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.

That GPU firmware is generally just a blob that has never been open sourced. The driver is the part that talks to the GPU, not the OS that runs inside the GPU. Unless I'm mistaken in which case this would be a huge deal.
Post reply on HN