Hopefully, we get a plain and simple C99 user space vulkan implementation.
NVIDIA Transitions Fully Towards Open-Source Linux GPU Kernel Modules
181–190 of 259 posts
Re: NVIDIA Transitions Fully Towards Open-Source Linux GPU Kernel Modules
#182Are Nvidia grace CPUs even available? I thought it was interesting they mentioned that.
Re: NVIDIA Transitions Fully Towards Open-Source Linux GPU Kernel Modules
#183What is GPU kernel module? Is it something like a driver for GPU?
Yes. In modern operating systems, GPU drivers usually consist in kernel component that is loaded inside of the kernel or in a privileged context, and a userspace component that talks with it and implements the GPU-specific part of the APIs that the windowing system and applications use. In the case of NVIDIA, they have decided to drop their proprietary kernel module in favour of an open one. Unfortunately, it's out of tree.
In Linux and BSD, you usually get all of your drivers with the system; you don't have to install anything, it's all mostly plug and play. For instance, this has been the case for AMD and Intel GPUs, which have a 100% open source stack. NVIDIA is particularly annoying due to the need to install the drivers separately and the fact they've got different implementations of things compared to anyone else, so NVIDIA users are often left behind by FOSS projects due to GeForce cards being more annoying to work with.
Re: NVIDIA Transitions Fully Towards Open-Source Linux GPU Kernel Modules
#184I really hope this makes it easier to install/upgrade NVIDIA drivers on Linux. It's a nightmare to figure out version mismatches between drivers, utils, container-runtime...
A nightmare how? When i used their cards, I'd just download the .run and run it. Done.
And when it doesn't work, what do you do then?
Exactly, that's when the nightmare starts.
Re: NVIDIA Transitions Fully Towards Open-Source Linux GPU Kernel Modules
#185There is little meaning for NVIDIA to open-source only the driver portion of their cards, since they heavily rely on proprietary firmware and userspace lib (most important!) to do the real job. Firmware is a relatively small issue - this is mostly same for AMD and Intel, since encapsulation reduces work done on driver side and open-sourcing firmware could allow people to do some really unanticipated modification whic…
It is meaningful because, as you note, it enables a fully opensource userspace driver. Of course the firmware is still proprietary and it increasingly contains more and more logic.
Re: NVIDIA Transitions Fully Towards Open-Source Linux GPU Kernel Modules
#186What is GPU kernel module? Is it something like a driver for GPU?
Yes. In modern operating systems, GPU drivers usually consist in kernel component that is loaded inside of the kernel or in a privileged context, and a userspace component that talks with it and implements the GPU-specific part of the APIs that the windowing system and applications use. In the case of NVIDIA, they have decided to drop their proprietary kernel module in favour of an open one. Unfortunately, it's out o…
Thanks. I'm not well versed in these things. It sounded like something you load into GPU (it reminded me old hp printer, which required firmware upload after start).
Re: NVIDIA Transitions Fully Towards Open-Source Linux GPU Kernel Modules
#187Earlier quoted context omitted.
As well isolated as anything else on the bus. So you better actually use IOMMU
> you better actually use IOMMU Is this feature commonly present on PC hardware? I've only ever read about it in the context of smartphone security. I've also read that nvidia doesn't like this sort of thing because it allows virtualizing their cards which is supposed to be an "enterprise" feature.
Relatively common nowadays. It used to be delineated as a feature in Intel chips as part of their vPro line, but I think it’s baked in. Generally an IOMMU is needed for performant PCI passthrough to VMs, and Windows uses it for DeviceGuard which tries to prevent DMA attacks.
Re: NVIDIA Transitions Fully Towards Open-Source Linux GPU Kernel Modules
#188Kernel is an overloaded term for GPUs. This is about the linux kernel
Guh, wish i could delete this now that the title was updated. the original title (shown on the linked page) wasn't super clear
Re: NVIDIA Transitions Fully Towards Open-Source Linux GPU Kernel Modules
#189There is little meaning for NVIDIA to open-source only the driver portion of their cards, since they heavily rely on proprietary firmware and userspace lib (most important!) to do the real job. Firmware is a relatively small issue - this is mostly same for AMD and Intel, since encapsulation reduces work done on driver side and open-sourcing firmware could allow people to do some really unanticipated modification whic…
It is meaningful because, as you note, it enables a fully opensource userspace driver. Of course the firmware is still proprietary and it increasingly contains more and more logic.
Which in a way is good because the hardware will more and more perform identically on Linux as on Windows.
Re: NVIDIA Transitions Fully Towards Open-Source Linux GPU Kernel Modules
#190Earlier quoted context omitted.
Having as open-source all the kernel, more precisely all the privileged code, is much more important for security than having as open-source all the firmware of the peripheral devices. Any closed-source privileged code cannot be audited and it may contain either intentional backdoors, or, more likely, bugs that can cause various undesirable effects, like crashes or privilege escalation. On the other hand, in a proper…
Everything you wrote assumes the IOMMUs across the board to be 100% correctly implemented without errors/bugdoors. People used to believe similar things about Hyperthreading, glitchability, ME, Cisco, boot-loaders, ... the list goes on.
There still is a huge difference between running privileged code on the CPU, for which there is nothing limiting what it can do, and code that runs on a device, which should normally be contained by the I/O MMU, except if the I/O MMU is buggy.
The functions of an I/O MMU for checking and filtering the transfers are very simple, so the probability of non-intentional bugs is extremely small in comparison with the other things enumerated by you.