You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What I'd like:
I would like to have the NVIDIA Open GPU kernel drivers available in Bottlerocket so that I can use EFA, this is related to #1031.
Ideally the driver would be chosen for the user depending on if the hardware supports the open driver. That way the correct driver is used automatically. The PCI device ID of the NVIDIA card can be used to determine if it supports the open kernel modules, if it does, then it would choose that driver instead of the current proprietary drivers in the NVIDIA variants.
The first step would be to compile in the driver from the .run archive in the kmod-5.15-nvidia and kmod-6.1-nvidia package in the core kit. Both sets of drivers can be included alongside each other and only the desired modules provided to modprobe on boot.
Currently, driverdog doesn't support the notion of two conflicting drivers (the proprietary and open source drivers use the same names and conflict with each other) so there needs to be a way to ensure driverdog only loads the desired driver. Ideally driverdog remains focused on linking and loading modules, and not on deciding which modules might be needed or choosing between configurations. ghostdog is already aware of PCI devices due to udev rules calling it so it would be a good place to put PCI device-specific code. driverdog also needs to solve the problem of only loading drivers if provided a configuration that doesn't call for linking. This will involve improving the structure of the configuration files since they assume each module needs linking when not all do (like the open GPU driver won't).
The PCI devices are enumerated pretty early in boot and ghostdog will be able to match those devices easily, but providing the right information later when driverdog needs it is the difficult part. Using /run or /etc could be racy because the PCI devices might enumerate before those filesystems are fully ready.
Any alternatives you've considered:
Providing a different NVIDIA variant that only has the open drivers would work as well, but then users would have to choose the correct variant. That would be the only change and would make it more confusing to figure out which variant is the right one.
The text was updated successfully, but these errors were encountered:
What I'd like:
I would like to have the NVIDIA Open GPU kernel drivers available in Bottlerocket so that I can use EFA, this is related to #1031.
Ideally the driver would be chosen for the user depending on if the hardware supports the open driver. That way the correct driver is used automatically. The PCI device ID of the NVIDIA card can be used to determine if it supports the open kernel modules, if it does, then it would choose that driver instead of the current proprietary drivers in the NVIDIA variants.
The first step would be to compile in the driver from the .run archive in the
kmod-5.15-nvidia
andkmod-6.1-nvidia
package in the core kit. Both sets of drivers can be included alongside each other and only the desired modules provided to modprobe on boot.Currently,
driverdog
doesn't support the notion of two conflicting drivers (the proprietary and open source drivers use the same names and conflict with each other) so there needs to be a way to ensure driverdog only loads the desired driver. Ideally driverdog remains focused on linking and loading modules, and not on deciding which modules might be needed or choosing between configurations.ghostdog
is already aware of PCI devices due to udev rules calling it so it would be a good place to put PCI device-specific code.driverdog
also needs to solve the problem of only loading drivers if provided a configuration that doesn't call for linking. This will involve improving the structure of the configuration files since they assume each module needs linking when not all do (like the open GPU driver won't).The PCI devices are enumerated pretty early in boot and
ghostdog
will be able to match those devices easily, but providing the right information later whendriverdog
needs it is the difficult part. Using/run
or/etc
could be racy because the PCI devices might enumerate before those filesystems are fully ready.Things needed for this to work:
kmod-*-nvidia
packages (Build open source NVIDIA kernel modules bottlerocket-core-kit#118)driverdog
to handle only loading a module if needed (Add the ability for driverdog to copy modules bottlerocket-core-kit#119)Any alternatives you've considered:
Providing a different NVIDIA variant that only has the open drivers would work as well, but then users would have to choose the correct variant. That would be the only change and would make it more confusing to figure out which variant is the right one.
The text was updated successfully, but these errors were encountered: