Nvidia releases open-source GPU kernel modules

If I recall properly, the command circular buffers of 2^n bytes ("queues" in vulkan3d) are VRAM IOMMAP-ed (you just need atomic R/W pointers for synchronization, see mathematically proven synchronization algorithms). There is a "GPU IRQ" circular buffer of 2^n bytes coupled with PCIE MSIs (and I recall something about a hardware "message box"). The "thing" is, for many of them, how to use those commands and how they are defined feels very weird (for instance the 3d/compute pipeline registers programing).

Have a look at libdrm from the mesa project (the AMDGPU submodule), then it will give you pointers where to look into the kernel-DRM via the right IOCTLs.

Basically, the kernel code is initialization, quirks detection and restoration (firmware blobs are failing hard here), setting up of the various vram virtual address spaces (16 on latest GPUs) and the various circular buffers. The 3D/compute pipeline programing is done from userspace via those circular buffers.

If I am not too much mistaken, on lastest GPU "everything" should be in 1 PCIE 64bits bar (thx to bar size reprograming).

The challenge for AMD is to make all that dead simple and clean while keeping the extreme performance (GPU is all about performance). Heard rumors about near 0-driver hardware (namely "rdy" at power up).

Linus' middle finger lowers slightly.

> this open-source release is nothing but a way to circumvent the GPL issues

Talking about strawman arguments... that's a doozie!

Instead of ignoring your strawman, staying focused on the topic...I'm going to address this nonesense...

Firstly Nvidia is not in violation of the GPL. Secondly, nobody cares about GPL violations, most certainly not the mainline kernel community. They do not pursue blatant GPL violations, because litigation is not productive in terms of improving the kernel, but keep in mind Nvidia is not violating the GPL. Thirdly, user space libraries that interface with a kernel API are not violating the GPL. Folks are allowed to run proprietary software on Linux. Do I like that, no... I certainly don't love it. However, Nvidia running user space graphics libraries is not much different than Radeon drivers using Mesa in userspace, it's how graphics architectures work in 2022.

So it's kidna ironic you're arguing about something separate (straw-man), and even then that argument fails...

Now then, putting your tangent aside... The whole point here is to start with the kernel, and get the kernel wrapper driver that interfaces with the hardware's firmware binary interface open sourced. The whole point is to get the driver into mainline, someday... Once we have that, we can untangle the the spaghetti of graphics API libraries, perhaps even port them to Mesa. Nvidia most certainly uses an intermediary low-level graphics representation for their graphics cards, so they can support all the various graphics APi's, or what not... it's a very common pattern for graphics cards... one Radeon even fell into not long ago. So it's just a matter of time before we decode this stuff.

But you're not wrong in terms of Nvidia's overall stack being proprietary, at least for now. But that's not important, what's important is Nvidia users wont' have so much drama when their distro kernel upgrades, and they screen goes blank thanks to Nvidia's driver not being compatible with the changed kernel ABI, and the AKMOD not being able to handle it.

> Have you ruled out power supply issues and are you running at stock clocks (for CPU and RAM as well)?

Yes for both. No overclocking whatsoever.

> Anyway, going from "at least once a week" to "once every 3 months" means that 90% of your crashes have been fixed.

I don't think I'm supposed to be ok with a device I paid premium money for crashing once every three months with no explanation from the manufacturer. They could've fixed 99% for all I care, it's still absurd that it's even an issue in the first place.

> What kind of message would you expect that would be more decipherable.

One that would lead me to an actual solution or at least an explanation, not just year old threads of people reporting this exact issue with replies saying it was fixed in kernel version X, where X is different for each thread.

Why?