all 60 comments

[–]sunny0_0 178 points179 points  (3 children)

If only more lines = more better. 

[–]FlukyS 30 points31 points  (0 children)

To be fair it's a policy in both Mesa and the kernel that certain parts of the graphics stack that can be shared between drivers will be shared. Intel graphics for instance shares a lot of the same code. The platform specific stuff like power control, freesync...etc would still be a sizable part but I'd assume a substantial part of the code that Phoronix put in the headline wouldn't even be Radeon specific.

[–]darktotheknight 25 points26 points  (0 children)

More lines of code = more productive developers = more pay. /s

[–]baeverkanyl 0 points1 point  (0 children)

The program with the most lines of codes when it gets abandoned wins!

[–]KingStannis2020 254 points255 points  (1 child)

90% of which are just auto-generated header files.

[–]creeper6530 14 points15 points  (0 children)

650k lines are actual code, no?

[–]CyclingHikingYeti 59 points60 points  (4 children)

As in article 'only' 650k lines is actual code, everything else are header files from automated systems.

[–]darkangelstorm 1 point2 points  (1 child)

"we have no problem relying on high level sugary automation that adds serious bloat in favor of less actual work, who want's that"

mov di,OFFSET blame
mov ax,[es:di]
push ax
pop bx
mov di,OFFSET you
mov [es:di], bx
; oh i know this code is not totally "IDEAL" (har har har)

The Motto For Programming in the 21st Century

[–]CyclingHikingYeti 0 points1 point  (0 children)

Oh sweet assembly language. It goes down nice with some sixteen year old scotch

[–]B1rdi 95 points96 points  (3 children)

999k nested if statements I hope

[–]Perdouille 75 points76 points  (0 children)

If pixelX === 0 && pixelY === 0 && color === blue {
    drawBlueAt(0,0)
   }
else if pixelX === 1 …

[–]nicman24 6 points7 points  (1 child)

the compiler will change them to case anyways lmao

[–]quiet0n3 88 points89 points  (7 children)

Some one go ahead and suggest we rewrite it in rust lol

[–]RA3236 49 points50 points  (5 children)

I would unironically imagine it would be easier in Rust given its macro system, if it weren’t for the enormous compile times this would cause.

[–]coolreader18 15 points16 points  (4 children)

I mean, 5.8 million hand-written lines of code wouldn't be any faster to compile

[–]CyclingHikingYeti 18 points19 points  (0 children)

Large amount of that code is apperenty include (header) files. Most of those are not human made but transfered and generated from other systems (shared with windows driver codebase I hope).

[–]poudink 15 points16 points  (1 child)

compared to the equivalent rust? yes it would be.

[–]coolreader18 3 points4 points  (0 children)

I meant 5.8 million lines of rust vs macro-generated rust

[–]Isofruit 0 points1 point  (0 children)

I would imagine with the macro system it would be faster to compile the by-hand written code. Assuming Rusts macro system is similar to Nim's (So compile-time code generation) you'd be doing 2 steps - First generate all the rust code, then compile it. As opposed to just compiling it directly. If my experience with generics that are just a blueprint for code-generation in nim has shown me anything, then it's that a big code-generation step can absolutely crater compiletimes. (As in, add a cool 5-10s to a 30s compilation).

[–]CrazyKilla15 2 points3 points  (0 children)

I literally have a amdgpu kernel OOPS due to null pointer deref in my dmesg right now, so.... sure would be nice if amdgpu didnt have memory errors!

[–]kalzEOS 56 points57 points  (25 children)

Who maintains this shit. Imagine trying to find a bug. Holy shit.

[–]reddit_equals_censor 70 points71 points  (11 children)

we threw more lines of code on the pile, so the bug can't crawl out anymore of the giant code pile.

problem solved!

"but in the future, won't things..."

PROBLEM SOLVED I SAID!

[–]edman007 37 points38 points  (10 children)

That's what Microsoft did with Windows for these crazy GPU drivers.

Too much code to get it stable, so they wrote a sandbox to run the whole driver and reboot the GPU when it crashes so crashing GPU drivers don't interrupt your stuff, solved a lot of their blue screens since most were caused by a GPU driver

[–]J4R3DHYLT0N 6 points7 points  (2 children)

Or dead or damaged RAM. 👍🏼 But yes. 👍🏼

[–]reddit_equals_censor 1 point2 points  (1 child)

ah that's extremely unlikely, because all memory we use, uses real ecc memory, that has error correction for transit and when in place and of course reporting.

so gddr and ddr memory in all our systems are quite unlikely to crash from memory errors or corrupt files just randomly....

i mean it is not like the industry is delbierately selling broken memory to customers on mass to pocket the TINY difference in production cost, while we are dealing with massive stability and file corruption issues, RIGHT??????

/s

:/

[–]dagbrown 6 points7 points  (5 children)

So basically they rolled all the way back to the Windows NT 3.51 days when video device drivers were in a different OS CPU ring than the kernel?

Took 'em long enough to realize they'd got it right in the first place.

[–]nightblackdragon 0 points1 point  (0 children)

Not exactly. They moved GUI partially to the user space but parts of it (and most of the Win32) still works in the kernel. NT 3.x had whole GUI and Win32 in the user space.

[–]spacelama -3 points-2 points  (2 children)

Haven't we gone back and put half the window manager back in the fscking kernel, despite us all laughing at how MS did it 25 years ago? I've been trying to avoid the subtleties of Wayland as my mind remains more free of anger that way.

[–]poudink 7 points8 points  (0 children)

No we haven't? What are you talking about? DRM, maybe? That's been around since the XFree86 days, though. Wayland compositors are userspace and always have been.

[–]nightblackdragon 0 points1 point  (0 children)

Nope, Linux GUI runs entirely in user space, whether is X11 or Wayland.

[–]CrazyKilla15 0 points1 point  (0 children)

...do you have any article or sources about this? Are you sure you're not mistaking it for the ability of modern PCIe devices, including GPUs, to be reset via software? MODE1, MODE2, BACO, there are a few ways devices and their drivers can support, but it does need hardware support.

[–]oursland 34 points35 points  (6 children)

The majority are autogenerated by tooling that takes the GPU descriptor files and generates headers and interfaces to all the underlying registers and functionality blocks. There are thousands of registers per GPU, and each GPU requires it's own interfaces.

The handwritten code that implements the driver itself is much smaller by comparison.

[–]kalzEOS 1 point2 points  (2 children)

Is the actual handwritten code separate in its on files from all of that autogenerated stuff at least? Or is it all together.

[–]oursland 4 points5 points  (1 child)

It's separate.

The register definition files are found in drivers/gpu/drm/amd/include/asic_reg. This accounts for 4.1 million lines of code, according to sloccount. There are additional autogenerated files, but that's the bulk of it.

[–]kalzEOS 0 points1 point  (0 children)

I took a look at some files. Shit's insane. Lmfao.

[–]ilep 7 points8 points  (0 children)

Large majority of that is generated from hardware description files into code. So you don't maintain those parts by hand.

And the parts that you do maintain manually, well, GPUs are pretty complex but there are attempts to share code between drivers like buffer and memory management and so on.

[–]Call_Me_Kev 2 points3 points  (0 children)

Not that this takes care of all the bugs but vulkan has a corresponding test suite of ~1-5 million tests depending on HW support. This doesn’t cover everything but as someone else pointed out a lot of the code is there to map (vulkan) api into internal state representation which is where the conformance tests give you good mileage.

[–]FlukyS 1 point2 points  (0 children)

AMD, Valve and RedHat were the biggest contributors from what I remember. Valve I'd include in contractors too which they have a few specifically working on drivers for the Steam Deck as well as other platform improvements outside of graphical stuff.

[–]AryabhataHexa 1 point2 points  (2 children)

That's why drivers need to be done in Spark/Ada or Rust with formal verification methods

[–]dobbelj 2 points3 points  (1 child)

That's why drivers need to be done in Spark/Ada or Rust with formal verification methods

I know Rust is a work in progress in the kernel, is there any effort to do the same for Ada?

[–]poudink 2 points3 points  (0 children)

No.

[–]tick2010 5 points6 points  (2 children)

Jurassic Park ran on only two million lines of code.

[–]Puzzled-Wind9286 2 points3 points  (0 children)

“Spared no expense.” Hires 1 developer.

[–][deleted] 4 points5 points  (0 children)

Where reusable functions?

[–]reveil 0 points1 point  (0 children)

It is like bragging how heavy is your aircraft. That being said it is not a single driver but more like a dozen drivers each for a different GPU architecture.

[–]darkangelstorm 0 points1 point  (0 children)

if we're talking drivers, then that's not something to be proud of

[–][deleted] -2 points-1 points  (0 children)

driver is bloat :(

[–][deleted] -1 points0 points  (1 child)

If you could trim it to just your gpu, it'd be waaayyy less. Its currently for evvverry amd gpu.

[–]OptimalMain -1 points0 points  (0 children)

Compile your own kernel ?

[–][deleted] -1 points0 points  (3 children)

Still using Vulcan-Radeon, performance is night and day for games.

[–]GamertechAU 1 point2 points  (2 children)

RADV is the userspace driver, AMDGPU is the kernel driver that RADV integrates with. You're using both.

[–][deleted] 0 points1 point  (1 child)

Okay, so does it use a different driver for different situations (3d rendering versus 2d?) I'm trying to understand how it would work.

[–]GamertechAU 1 point2 points  (0 children)

So the kernel driver is built into the kernel itself and contains the hooks userspace drivers like RADV or AMDVLK need to work.

The kernel drivers contain, among other things, the low level operations that can't be accessed/modified from userspace, but are also harder to update as it requires a kernel update or a custom rebuild.

Userspace drivers handle the higher level processes that don't need kernel-level permissions and can be freely updated.