NetCube-Systems-Austria/kumquat-buildroot
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
dbc18a7101
kumquat-buildroot/package/nvidia-driver/Config.in

89 lines
2.4 KiB
Plaintext
Raw Normal View History

package/nvidia-driver: CUDA support does not require X.org Currently, nvidia-driver always installs the X.org driver, assuming this is a requirement for all functionalities provided by nvidia-driver, thus pulling in quite a bunch of X.org packages. However, it is perfectly legit to be doing CUDA (and OpenCL) work without the full X.org stack, and indeed the NVidia CUDA and OpenCL libraries do not require the X.org stack. Split the configuration so that it is posible to install the different parts independently from each others, so that CUDA can be installed all on its own. Reported-by: Al West <al.west@v-nova.com> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Al West <al.west@v-nova.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-03-31 19:45:34 +02:00
comment "nvidia-driver needs an (e)glibc toolchain"
package/nvidia-driver: add NVidia's OpenGL binary blob This patch only adds the userland part. Unless other such other packages (which we named like: rpi-userland), we do not replicate this naming scheme with this package, as a future patch will also enable building the kernel part of the driver. So, it is better to just name that package with -driver, rather than with -userland and renaming it afterwards. [Thomas: - Rewrap Config.in help text. - Add a comment to explain why mesa3d-headers, xlib_libX11 and xlib_libXext are part of the dependencies. - Fix typo in comment about library installation: s/The/Then/ - Use 'addsuffix' instead of 'patsubst' to calculate the final filename of libraries to install. - Use more temporary variables to make the library installation loop clearer: 'libpath' is the relative path of the library in nvidia-driver sources, 'libname' the base name of the library, 'libsoname' the soname of the library, and 'baseso' the base .so symlink name.] Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-02-10 21:01:12 +01:00
depends on BR2_i386 || BR2_x86_64
package/nvidia-driver: CUDA support does not require X.org Currently, nvidia-driver always installs the X.org driver, assuming this is a requirement for all functionalities provided by nvidia-driver, thus pulling in quite a bunch of X.org packages. However, it is perfectly legit to be doing CUDA (and OpenCL) work without the full X.org stack, and indeed the NVidia CUDA and OpenCL libraries do not require the X.org stack. Split the configuration so that it is posible to install the different parts independently from each others, so that CUDA can be installed all on its own. Reported-by: Al West <al.west@v-nova.com> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Al West <al.west@v-nova.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-03-31 19:45:34 +02:00
depends on !BR2_TOOLCHAIN_USES_GLIBC
package/nvidia-driver: add NVidia's OpenGL binary blob This patch only adds the userland part. Unless other such other packages (which we named like: rpi-userland), we do not replicate this naming scheme with this package, as a future patch will also enable building the kernel part of the driver. So, it is better to just name that package with -driver, rather than with -userland and renaming it afterwards. [Thomas: - Rewrap Config.in help text. - Add a comment to explain why mesa3d-headers, xlib_libX11 and xlib_libXext are part of the dependencies. - Fix typo in comment about library installation: s/The/Then/ - Use 'addsuffix' instead of 'patsubst' to calculate the final filename of libraries to install. - Use more temporary variables to make the library installation loop clearer: 'libpath' is the relative path of the library in nvidia-driver sources, 'libname' the base name of the library, 'libsoname' the soname of the library, and 'baseso' the base .so symlink name.] Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-02-10 21:01:12 +01:00
config BR2_PACKAGE_NVIDIA_DRIVER
bool "nvidia-driver"
depends on BR2_i386 || BR2_x86_64
depends on BR2_TOOLCHAIN_USES_GLIBC
package/nvidia-driver: CUDA support does not require X.org Currently, nvidia-driver always installs the X.org driver, assuming this is a requirement for all functionalities provided by nvidia-driver, thus pulling in quite a bunch of X.org packages. However, it is perfectly legit to be doing CUDA (and OpenCL) work without the full X.org stack, and indeed the NVidia CUDA and OpenCL libraries do not require the X.org stack. Split the configuration so that it is posible to install the different parts independently from each others, so that CUDA can be installed all on its own. Reported-by: Al West <al.west@v-nova.com> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Al West <al.west@v-nova.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-03-31 19:45:34 +02:00
help
The binary-only driver blob for NVidia cards.
This is the userland part only.
http://www.nvidia.com/
if BR2_PACKAGE_NVIDIA_DRIVER
comment "nvidia-driver X.org drivers needs a modular Xorg server"
depends on !BR2_PACKAGE_XSERVER_XORG_SERVER_MODULAR
config BR2_PACKAGE_NVIDIA_DRIVER_XORG
bool "X.org drivers"
default y
package/nvidia-driver: add NVidia's OpenGL binary blob This patch only adds the userland part. Unless other such other packages (which we named like: rpi-userland), we do not replicate this naming scheme with this package, as a future patch will also enable building the kernel part of the driver. So, it is better to just name that package with -driver, rather than with -userland and renaming it afterwards. [Thomas: - Rewrap Config.in help text. - Add a comment to explain why mesa3d-headers, xlib_libX11 and xlib_libXext are part of the dependencies. - Fix typo in comment about library installation: s/The/Then/ - Use 'addsuffix' instead of 'patsubst' to calculate the final filename of libraries to install. - Use more temporary variables to make the library installation loop clearer: 'libpath' is the relative path of the library in nvidia-driver sources, 'libname' the base name of the library, 'libsoname' the soname of the library, and 'baseso' the base .so symlink name.] Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-02-10 21:01:12 +01:00
depends on BR2_PACKAGE_XSERVER_XORG_SERVER_MODULAR
select BR2_PACKAGE_MESA3D_HEADERS
select BR2_PACKAGE_XLIB_LIBX11
select BR2_PACKAGE_XLIB_LIBXEXT
select BR2_PACKAGE_HAS_LIBGL
select BR2_PACKAGE_HAS_LIBEGL
select BR2_PACKAGE_HAS_LIBGLES
package/nvidia-driver: CUDA support does not require X.org Currently, nvidia-driver always installs the X.org driver, assuming this is a requirement for all functionalities provided by nvidia-driver, thus pulling in quite a bunch of X.org packages. However, it is perfectly legit to be doing CUDA (and OpenCL) work without the full X.org stack, and indeed the NVidia CUDA and OpenCL libraries do not require the X.org stack. Split the configuration so that it is posible to install the different parts independently from each others, so that CUDA can be installed all on its own. Reported-by: Al West <al.west@v-nova.com> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Al West <al.west@v-nova.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-03-31 19:45:34 +02:00
if BR2_PACKAGE_NVIDIA_DRIVER_XORG
package/nvidia-driver: add NVidia's OpenGL binary blob This patch only adds the userland part. Unless other such other packages (which we named like: rpi-userland), we do not replicate this naming scheme with this package, as a future patch will also enable building the kernel part of the driver. So, it is better to just name that package with -driver, rather than with -userland and renaming it afterwards. [Thomas: - Rewrap Config.in help text. - Add a comment to explain why mesa3d-headers, xlib_libX11 and xlib_libXext are part of the dependencies. - Fix typo in comment about library installation: s/The/Then/ - Use 'addsuffix' instead of 'patsubst' to calculate the final filename of libraries to install. - Use more temporary variables to make the library installation loop clearer: 'libpath' is the relative path of the library in nvidia-driver sources, 'libname' the base name of the library, 'libsoname' the soname of the library, and 'baseso' the base .so symlink name.] Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-02-10 21:01:12 +01:00
config BR2_PACKAGE_PROVIDES_LIBGL
default "nvidia-driver"
config BR2_PACKAGE_PROVIDES_LIBEGL
default "nvidia-driver"
config BR2_PACKAGE_PROVIDES_LIBGLES
default "nvidia-driver"
config BR2_PACKAGE_NVIDIA_DRIVER_PRIVATE_LIBS
bool "Install private libraries"
help
Two libraries require special agreement with NVidia to
develop code linking to those libraries: libnvidia-ifr.so
and libnvidia-fbc.so (to grab and encode an OpenGL buffer or
an X framebuffer.)
Say 'y' here if you plan on running a program that uses
those private libraries.
package/nvidia-driver: CUDA support does not require X.org Currently, nvidia-driver always installs the X.org driver, assuming this is a requirement for all functionalities provided by nvidia-driver, thus pulling in quite a bunch of X.org packages. However, it is perfectly legit to be doing CUDA (and OpenCL) work without the full X.org stack, and indeed the NVidia CUDA and OpenCL libraries do not require the X.org stack. Split the configuration so that it is posible to install the different parts independently from each others, so that CUDA can be installed all on its own. Reported-by: Al West <al.west@v-nova.com> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Al West <al.west@v-nova.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-03-31 19:45:34 +02:00
endif # BR2_PACKAGE_NVIDIA_DRIVER_XORG
config BR2_PACKAGE_NVIDIA_DRIVER_CUDA
bool "CUDA support"
package/nvidia-driver: add option to install CUDA MPS server Using CUDA with NVidia requires those two programs if one wants to use more than one program doing CUDA at the same time. This is only available on x86_64. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Al West <al.west@v-nova.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-03-31 19:45:35 +02:00
if BR2_PACKAGE_NVIDIA_DRIVER_CUDA
package/nvidia-driver: CUDA support does not require X.org Currently, nvidia-driver always installs the X.org driver, assuming this is a requirement for all functionalities provided by nvidia-driver, thus pulling in quite a bunch of X.org packages. However, it is perfectly legit to be doing CUDA (and OpenCL) work without the full X.org stack, and indeed the NVidia CUDA and OpenCL libraries do not require the X.org stack. Split the configuration so that it is posible to install the different parts independently from each others, so that CUDA can be installed all on its own. Reported-by: Al West <al.west@v-nova.com> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Al West <al.west@v-nova.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-03-31 19:45:34 +02:00
config BR2_PACKAGE_NVIDIA_DRIVER_OPENCL
bool "OpenCL support"
package/nvidia-driver: add option to install CUDA MPS server Using CUDA with NVidia requires those two programs if one wants to use more than one program doing CUDA at the same time. This is only available on x86_64. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Al West <al.west@v-nova.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-03-31 19:45:35 +02:00
config BR2_PACKAGE_NVIDIA_DRIVER_CUDA_PROGS
bool "CUDA MPS server and control"
depends on BR2_x86_64
help
Say 'y' here if you need to run more than one program
doing CUDA at the same time. The MPS server will be
launched automatically when needed.
endif # BR2_PACKAGE_NVIDIA_DRIVER_CUDA
package/nvidia-driver: CUDA support does not require X.org Currently, nvidia-driver always installs the X.org driver, assuming this is a requirement for all functionalities provided by nvidia-driver, thus pulling in quite a bunch of X.org packages. However, it is perfectly legit to be doing CUDA (and OpenCL) work without the full X.org stack, and indeed the NVidia CUDA and OpenCL libraries do not require the X.org stack. Split the configuration so that it is posible to install the different parts independently from each others, so that CUDA can be installed all on its own. Reported-by: Al West <al.west@v-nova.com> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Al West <al.west@v-nova.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-03-31 19:45:34 +02:00
package/nvidia-driver: build the kernel module Add option to build the nvidia.ko module. If CUDA is enabled on x86_64, also build the nvidia-uvm.ko kernel module (for Unified Memory access), which is required by the CUDA user-land library. Substancially inspired by the corresponding Gentoo ebuild: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/x11-drivers/nvidia-drivers/nvidia-drivers-340.32.ebuild?revision=1.2&view=markup [Thomas: - add quotes when using $(TARGET_CC) and other variables, since they can have spaces in their values - remove space after opening parenthesis and before closing parenthesis.] Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-02-10 21:01:14 +01:00
comment "nvidia kernel module needs a kernel to be built"
depends on !BR2_LINUX_KERNEL
config BR2_PACKAGE_NVIDIA_DRIVER_MODULE
bool "nvidia kernel module"
depends on BR2_LINUX_KERNEL
package/nvidia-driver: require kernel modules from Kconfig Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2015-12-10 19:53:15 +01:00
select BR2_LINUX_NEEDS_MODULES # not using kernel-module infra
package/nvidia-driver: build the kernel module Add option to build the nvidia.ko module. If CUDA is enabled on x86_64, also build the nvidia-uvm.ko kernel module (for Unified Memory access), which is required by the CUDA user-land library. Substancially inspired by the corresponding Gentoo ebuild: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/x11-drivers/nvidia-drivers/nvidia-drivers-340.32.ebuild?revision=1.2&view=markup [Thomas: - add quotes when using $(TARGET_CC) and other variables, since they can have spaces in their values - remove space after opening parenthesis and before closing parenthesis.] Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-02-10 21:01:14 +01:00
help
Build the nvidia.ko kernel module.
If CUDA support (above) is set, and the target is x86_64, then
this will also build the nvidia-uvm.ko kernel module, which
provides Unified Memory access to the GPU and CPU memories for
CUDA programs.
package/nvidia-driver: add NVidia's OpenGL binary blob This patch only adds the userland part. Unless other such other packages (which we named like: rpi-userland), we do not replicate this naming scheme with this package, as a future patch will also enable building the kernel part of the driver. So, it is better to just name that package with -driver, rather than with -userland and renaming it afterwards. [Thomas: - Rewrap Config.in help text. - Add a comment to explain why mesa3d-headers, xlib_libX11 and xlib_libXext are part of the dependencies. - Fix typo in comment about library installation: s/The/Then/ - Use 'addsuffix' instead of 'patsubst' to calculate the final filename of libraries to install. - Use more temporary variables to make the library installation loop clearer: 'libpath' is the relative path of the library in nvidia-driver sources, 'libname' the base name of the library, 'libsoname' the soname of the library, and 'baseso' the base .so symlink name.] Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-02-10 21:01:12 +01:00
endif # BR2_PACKAGE_NVIDIA_DRIVER
Reference in New Issue Copy Permalink