Skip to contentSkip to conversation

Introduce NVidia's binary driver (branch yem/gfx)

PATCH New Yann E. MORIN 2 participants 11 messages Sep 21, 2014 – Oct 5, 2014

lore
Share & tools
lore

Yann E. MORIN

author
#0 lore raw

v2 cover Introduce NVidia's binary driver (branch yem/gfx)

Hello All!

This series adds support for NVidia's binary blob, the driver to its family of GPUs.

It also introduces the OpenGL Registry, to provide GL headers for those OpenGL/EGL/GLES implementations that do not provide their own headers (like NVidia's binary blob.)

The series was build-tested using XBMC as a test-bed (I managed a single runtime test, as my HTPC is a bit reluctant at booting from a USB key when the internal HDD is present, so I can't easily retest.)

Changes v1 -> v2:
- bump opengl-registry
- drop i915, applied (Peter)

Regards,
Yann E. MORIN.

The following changes since commit ae69eadaa7b98fb73cbc5dcf8454e54a5189dd9b:

pkg-infra: put optional step_user def and assignment in one block (2014-09-21 22:57:30 +0200)

are available in the git repository at:

git://gitorious.org/buildroot/buildroot.git yem/gfx

for you to fetch changes up to 1aff79ec2bb8dc545496e965aa1fae0756be29ce:

package/nvidia-driver: build the kernel module (2014-09-21 23:13:03 +0200)

----------------------------------------------------------------
Yann E. MORIN (3):
package/opengl-registry: new package package/nvidia-driver: add NVidia's OpenGL binary blob package/nvidia-driver: build the kernel module

 package/Config.in                                  |    2 +
 package/nvidia-driver/Config.in                    |   77 +
 package/nvidia-driver/nvidia-driver.mk             |  141 ++
 package/opengl-registry/Config.in                  |   18 +
 package/opengl-registry/gl.h                       | 2115 ++++++++++++++++++++
 .../opengl-registry-000-run-from-current-dir.patch |   17 +
 package/opengl-registry/opengl-registry.mk         |   76 +
 7 files changed, 2446 insertions(+)
 create mode 100644 package/nvidia-driver/Config.in
 create mode 100644 package/nvidia-driver/nvidia-driver.mk
 create mode 100644 package/opengl-registry/Config.in
 create mode 100644 package/opengl-registry/gl.h
 create mode 100644 package/opengl-registry/opengl-registry-000-run-from-current-dir.patch
 create mode 100644 package/opengl-registry/opengl-registry.mk
Signature · 6 lines
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
author
#1 lore raw

PATCH v2 1/3 package/opengl-registry: new package

OpenGL Registry provides all GL headers, save for gl.h itself. We vampirise the one from mesa3d (at the version we currently package), which is as good as any other.

We use the last svn revision at which the api directory was *changed*, not the revision the repository is currently at.

Those headers are needed when an OpenGL/EGL/GLES implementation does not provide its own headers, like the NVidia binary blob (to come in follow-up patches.)

Signed-off-by "Yann E. MORIN" <[email protected]>

--
Tested by building XBMC against the NVidia proprietary blob.

---
 package/Config.in                                  |    1 +
 package/opengl-registry/Config.in                  |   18 +
 package/opengl-registry/gl.h                       | 2115 ++++++++++++++++++++
 .../opengl-registry-000-run-from-current-dir.patch |   17 +
 package/opengl-registry/opengl-registry.mk         |   76 +
 5 files changed, 2227 insertions(+)
 create mode 100644 package/opengl-registry/Config.in
 create mode 100644 package/opengl-registry/gl.h
 create mode 100644 package/opengl-registry/opengl-registry-000-run-from-current-dir.patch
 create mode 100644 package/opengl-registry/opengl-registry.mk
package/Config.in +1 -0
index 2eefc3f..9a81f59 100644
@@ -649,6 +649,7 @@ menu "Graphics"
 	source "package/libva-intel-driver/Config.in"
 	source "package/opencv/Config.in"
 	source "package/opengl/Config.in"
+	source "package/opengl-registry/Config.in"
 	source "package/pango/Config.in"
 	source "package/pixman/Config.in"
 	source "package/poppler/Config.in"
package/opengl-registry/Config.in new file +18 -0
new file mode 100644
index 0000000..1d4566b
@@ -0,0 +1,18 @@
+config BR2_PACKAGE_OPENGL_REGISTRY
+	bool "opengl-registry"
+	depends on BR2_PACKAGE_HAS_LIBGL || BR2_PACKAGE_HAS_LIBGLES || BR2_PACKAGE_HAS_LIBEGL
+	help
+	  The OpenGL Registry contains specifications, header files, and
+	  related documentation for OpenGL and related APIs including GLU,
+	  GLX, and WGL. In addition to the core API specifications, many
+	  extensions to these APIs have been defined by vendors, groups of
+	  vendors, and the ARB. The Registry also contains specifications
+	  and header files for all registered extensions, written as
+	  modifications to the appropriate core API specifications.
+
+	  This package installs the openGL header files. You do not need them
+	  if the OpenGL/EGL/GLES implementation provides its own headers.
+	  Currently, the only known implementation requiring OpenGL Resgistry
+	  is the NVidia proprietary driver.
+
+	  https://www.opengl.org/registry/
package/opengl-registry/gl.h new file +2115 -0

2,115 lines not on this page · raw message

package/opengl-registry/opengl-registry-000-run-from-current-dir.patch new file +17 -0
new file mode 100644
index 0000000..4b042ab
@@ -0,0 +1,17 @@
+Makefile: allow running without the current dir in PATH
+
+Signed-off-by: "Yann E. MORIN" <[email protected]>
+
+Index: a/Makefile
+===================================================================
+--- a/Makefile	(revision 27863)
++++ a/Makefile	(working copy)
+@@ -24,7 +24,7 @@
+ 
+ PYFILES = genheaders.py reg.py
+ GENOPTS =
+-GENHEADERS = genheaders.py $(GENOPTS)
++GENHEADERS = ./genheaders.py $(GENOPTS)
+ 
+ # Generate all headers for GL / GLES / WGL / GLX / EGL
+ # Different headers depend on different XML registry files
package/opengl-registry/opengl-registry.mk new file +76 -0

76 lines not on this page · raw message

Signature · 1 line
1.9.1
#2 lore raw

PATCH v2 1/3 package/opengl-registry: new package

Dear Yann E. MORIN,

Quoted 2 lines · Yann E. MORIN

We use the last svn revision at which the api directory was *changed*, not the revision the repository is currently at.

Why does this matter?

Quoted 3 lines
 package/Config.in                                  |    1 +
 package/opengl-registry/Config.in                  |   18 +
 package/opengl-registry/gl.h                       | 2115 ++++++++++++++++++++

Hum, I was wondering if we couldn't instead download this file from the Mesa git repository instead. But looks like <pkg>_EXTRA_DOWNLOADS assumes the file is located at the same URL as <pkg>_SOURCE.

Do we know why this gl.h is not part of the upstream opengl-registry?

Quoted 14 lines
package/opengl-registry/Config.in new file +8 -0
new file mode 100644
index 0000000..1d4566b
@@ -0,0 +1,18 @@
+config BR2_PACKAGE_OPENGL_REGISTRY
+	bool "opengl-registry"
+	depends on BR2_PACKAGE_HAS_LIBGL || BR2_PACKAGE_HAS_LIBGLES || BR2_PACKAGE_HAS_LIBEGL
+	help
+	  The OpenGL Registry contains specifications, header files, and
+	  related documentation for OpenGL and related APIs including GLU,
+	  GLX, and WGL. In addition to the core API specifications, many
+	  extensions to these APIs have been defined by vendors, groups of

package/opengl-registry/Config.in line 18

Quoted 10 lines
package/opengl-registry/Config.in new file +10 -0
+	  vendors, and the ARB. The Registry also contains specifications
+	  and header files for all registered extensions, written as
+	  modifications to the appropriate core API specifications.
+
+	  This package installs the openGL header files. You do not need them
+	  if the OpenGL/EGL/GLES implementation provides its own headers.
+	  Currently, the only known implementation requiring OpenGL Resgistry
+	  is the NVidia proprietary driver.
+
+	  https://www.opengl.org/registry/

Should we foresee any problem if an OpenGL implementation providing its own header files (e.g rpi-userland, gpu-imx, etc.) gets selected in addition to this package? They will overwrite each other files, no?

Quoted 19 lines
package/opengl-registry/opengl-registry.mk new file +13 -0
new file mode 100644
index 0000000..0c4da28
@@ -0,0 +1,76 @@
+################################################################################
+#
+# opengl-registry
+#
+################################################################################
+
+# Using last revision at which the 'api' directory was *changed*
+OPENGL_REGISTRY_VERSION = 28221
+OPENGL_REGISTRY_SITE = https://cvs.khronos.org/svn/repos/ogl/trunk/doc/registry/public/api
+OPENGL_REGISTRY_SITE_METHOD = svn
+# The license is MIT, but with 's/Software/Materials/' so it is not exactly MIT
+OPENGL_REGISTRY_LICENSE = MIT-like
+# No license file, license header in all generated headers

package/opengl-registry/opengl-registry.mk line 23

Quoted 10 lines
package/opengl-registry/opengl-registry.mk new file +10 -0
+
+# The registry only installs header files
+OPENGL_REGISTRY_INSTALL_STAGING = YES
+OPENGL_REGISTRY_INSTALL_TARGET = NO
+
+# opengl-registry depends on at least one of those virtual packages,
+# so we can be sure we'll have _DIRS set to non-empty.
+OPENGL_REGISTRY_DIRS = $(if $(BR2_PACKAGE_HAS_LIBGL),GL)
+OPENGL_REGISTRY_DIRS += $(if $(BR2_PACKAGE_HAS_LIBEGL),EGL)
+OPENGL_REGISTRY_DIRS += $(if $(BR2_PACKAGE_HAS_LIBGLES),GLES GLES2 GLES3)

Maybe just:

OPENGL_REGISTRY_DIRS = \
	$(if $(BR2_PACKAGE_HAS_LIBGL),GL) \
	$(if $(BR2_PACKAGE_HAS_LIBEGL),EGL) \
	$(if $(BR2_PACKAGE_HAS_LIBGLES),GLES GLES2 GLES3)

package/opengl-registry/opengl-registry.mk line 34

Quoted 10 lines
package/opengl-registry/opengl-registry.mk new file +10 -0
+# Remove pre-generated files
+define OPENGL_REGISTRY_RM_H
+	rm -f $(@D)/GL/*.h
+endef
+OPENGL_REGISTRY_POST_EXTRACT_HOOKS += OPENGL_REGISTRY_RM_H
+
+# We need to tweak glx.h to:
+# - include the X11 headers it needs
+# - include glxext.h like mesa3d's one does
+# - define the glxext prototypes

Why not simply use a patch instead of this awk magic? We generally use patches when possible. In this case, you're patching only one file, so clearly a patch seems to make sense here, no?

Thanks,

Thomas

Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
author
#3 lore raw

PATCH v2 1/3 package/opengl-registry: new package

Thomas, All,

On 2014-10-05 18:47 +0200, Thomas Petazzoni spake thusly:

Quoted 8 lines

Dear Yann E. MORIN,

Quoted 2 lines · Yann E. MORIN

We use the last svn revision at which the api directory was *changed*, not the revision the repository is currently at.

Why does this matter?

It does not matter. It is just a note that the revision used might be different than the current revision in the SVN tree, because the tree contains many other things than the registry, some of which are not even public.

Quoted 7 lines
Quoted 3 lines
 package/Config.in                                  |    1 +
 package/opengl-registry/Config.in                  |   18 +
 package/opengl-registry/gl.h                       | 2115 ++++++++++++++++++++

Hum, I was wondering if we couldn't instead download this file from the Mesa git repository instead. But looks like <pkg>_EXTRA_DOWNLOADS assumes the file is located at the same URL as <pkg>_SOURCE.

Yes, that's still the case. I remember we already had this discussion a while ago, but it is still not possible to provide a complete URL for extra downloads.

If that was to change, then yes, we could download it rather than bundle it.

Quoted 1 line

Do we know why this gl.h is not part of the upstream opengl-registry?

No, I have no idea.

Quoted 20 lines
Quoted 20 lines
package/opengl-registry/Config.in new file +14 -0
new file mode 100644
index 0000000..1d4566b
@@ -0,0 +1,18 @@
+config BR2_PACKAGE_OPENGL_REGISTRY
+	bool "opengl-registry"
+	depends on BR2_PACKAGE_HAS_LIBGL || BR2_PACKAGE_HAS_LIBGLES || BR2_PACKAGE_HAS_LIBEGL
+	help
+	  The OpenGL Registry contains specifications, header files, and
+	  related documentation for OpenGL and related APIs including GLU,
+	  GLX, and WGL. In addition to the core API specifications, many
+	  extensions to these APIs have been defined by vendors, groups of
+	  vendors, and the ARB. The Registry also contains specifications
+	  and header files for all registered extensions, written as
+	  modifications to the appropriate core API specifications.
+
+	  This package installs the openGL header files. You do not need them
+	  if the OpenGL/EGL/GLES implementation provides its own headers.
Quoted 8 lines

package/opengl-registry/Config.in line 18

Quoted 4 lines
package/opengl-registry/Config.in new file +4 -0
+	  Currently, the only known implementation requiring OpenGL Resgistry
+	  is the NVidia proprietary driver.
+
+	  https://www.opengl.org/registry/

Should we foresee any problem if an OpenGL implementation providing its own header files (e.g rpi-userland, gpu-imx, etc.) gets selected in addition to this package? They will overwrite each other files, no?

Hmm.. I think I thought about that when I did the patch, I can't remember what I came up with as a conclusion. Lemme think about it once again...

Quoted 32 lines
Quoted 19 lines
package/opengl-registry/opengl-registry.mk new file +13 -0
new file mode 100644
index 0000000..0c4da28
@@ -0,0 +1,76 @@
+################################################################################
+#
+# opengl-registry
+#
+################################################################################
+
+# Using last revision at which the 'api' directory was *changed*
+OPENGL_REGISTRY_VERSION = 28221
+OPENGL_REGISTRY_SITE = https://cvs.khronos.org/svn/repos/ogl/trunk/doc/registry/public/api
+OPENGL_REGISTRY_SITE_METHOD = svn
+# The license is MIT, but with 's/Software/Materials/' so it is not exactly MIT
+OPENGL_REGISTRY_LICENSE = MIT-like
+# No license file, license header in all generated headers

package/opengl-registry/opengl-registry.mk line 23

Quoted 10 lines
package/opengl-registry/opengl-registry.mk new file +10 -0
+
+# The registry only installs header files
+OPENGL_REGISTRY_INSTALL_STAGING = YES
+OPENGL_REGISTRY_INSTALL_TARGET = NO
+
+# opengl-registry depends on at least one of those virtual packages,
+# so we can be sure we'll have _DIRS set to non-empty.
+OPENGL_REGISTRY_DIRS = $(if $(BR2_PACKAGE_HAS_LIBGL),GL)
+OPENGL_REGISTRY_DIRS += $(if $(BR2_PACKAGE_HAS_LIBEGL),EGL)
+OPENGL_REGISTRY_DIRS += $(if $(BR2_PACKAGE_HAS_LIBGLES),GLES GLES2 GLES3)

Maybe just:

Quoted 4 lines
OPENGL_REGISTRY_DIRS = \
	$(if $(BR2_PACKAGE_HAS_LIBGL),GL) \
	$(if $(BR2_PACKAGE_HAS_LIBEGL),EGL) \
	$(if $(BR2_PACKAGE_HAS_LIBGLES),GLES GLES2 GLES3)

OK.

Quoted 6 lines
Quoted 6 lines
package/opengl-registry/opengl-registry.mk new file +6 -0
+# Remove pre-generated files
+define OPENGL_REGISTRY_RM_H
+	rm -f $(@D)/GL/*.h
+endef
+OPENGL_REGISTRY_POST_EXTRACT_HOOKS += OPENGL_REGISTRY_RM_H
+
Quoted 8 lines

package/opengl-registry/opengl-registry.mk line 34

Quoted 4 lines
package/opengl-registry/opengl-registry.mk new file +4 -0
+# We need to tweak glx.h to:
+# - include the X11 headers it needs
+# - include glxext.h like mesa3d's one does
+# - define the glxext prototypes

Why not simply use a patch instead of this awk magic? We generally use patches when possible. In this case, you're patching only one file, so clearly a patch seems to make sense here, no?

Because it is done after the build, and changs a generated file.

Regards,
Yann E. MORIN.

Signature · 6 lines
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
#4 lore raw

PATCH v2 1/3 package/opengl-registry: new package

Dear Yann E. MORIN,

Quoted 9 lines · Yann E. MORIN
Quoted 4 lines
Quoted 2 lines

We use the last svn revision at which the api directory was *changed*, not the revision the repository is currently at.

Why does this matter?

It does not matter. It is just a note that the revision used might be different than the current revision in the SVN tree, because the tree contains many other things than the registry, some of which are not even public.

Hum, ok. I found it a bit weird.

Quoted 9 lines
Quoted 8 lines
Quoted 4 lines
 package/Config.in                                  |    1 +
 package/opengl-registry/Config.in                  |   18 +
 package/opengl-registry/gl.h                       | 2115 ++++++++++++++++++++

Hum, I was wondering if we couldn't instead download this file from the Mesa git repository instead. But looks like <pkg>_EXTRA_DOWNLOADS assumes the file is located at the same URL as <pkg>_SOURCE.

Quoted 6 lines

Yes, that's still the case. I remember we already had this discussion a while ago, but it is still not possible to provide a complete URL for extra downloads.

If that was to change, then yes, we could download it rather than bundle it.

Yes, agreed. For now I guess bundling it would be fine.

Quoted 3 lines
Quoted 1 line

Do we know why this gl.h is not part of the upstream opengl-registry?

No, I have no idea.

Do you know if there's some sort of upstream to which we could report what looks like a "bug" ?

I was wondering what other distributions do, and seems like Ubuntu is also adding all those headers through a big patch.

Quoted 11 lines
Quoted 10 lines

package/opengl-registry/Config.in line 18

Quoted 6 lines
package/opengl-registry/Config.in new file +6 -0
+	  This package installs the openGL header files. You do not need them
+	  if the OpenGL/EGL/GLES implementation provides its own headers.
+	  Currently, the only known implementation requiring OpenGL Resgistry
+	  is the NVidia proprietary driver.
+
+	  https://www.opengl.org/registry/

Should we foresee any problem if an OpenGL implementation providing its own header files (e.g rpi-userland, gpu-imx, etc.) gets selected in addition to this package? They will overwrite each other files, no?

Quoted 3 lines

Hmm.. I think I thought about that when I did the patch, I can't remember what I came up with as a conclusion. Lemme think about it once again...

For safety, should we ensure this package only gets selected together with the NVidia driver? Don't know exactly since we can't have A depends on B, and B select A. Make opengl-registry a blind option, so that people cannot select it, and even autobuilders will not select it, except as a dependency of the NVidia driver package.

Quoted 15 lines
Quoted 6 lines
Quoted 6 lines
package/opengl-registry/opengl-registry.mk new file +6 -0
+# Remove pre-generated files
+define OPENGL_REGISTRY_RM_H
+	rm -f $(@D)/GL/*.h
+endef
+OPENGL_REGISTRY_POST_EXTRACT_HOOKS += OPENGL_REGISTRY_RM_H
+
Quoted 8 lines

package/opengl-registry/opengl-registry.mk line 34

Quoted 4 lines
package/opengl-registry/opengl-registry.mk new file +4 -0
+# We need to tweak glx.h to:
+# - include the X11 headers it needs
+# - include glxext.h like mesa3d's one does
+# - define the glxext prototypes

Why not simply use a patch instead of this awk magic? We generally use patches when possible. In this case, you're patching only one file, so clearly a patch seems to make sense here, no?

Quoted 1 line

Because it is done after the build, and changs a generated file.

Aaah, yes, indeed. I guess the generation logic is too complicated to be patched. So, we'll have to keep the awk magic. Maybe add a short comment that mentions that it's done after the headers have been generated.

Also, this is using some Python script to generate the headers. Is this Python script only using the Python standard library for XML, or is it using some external Python library that will cause troubles in terms of Buildroot "core" dependencies?

Thanks!

Thomas

Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
author
#5 lore raw

PATCH v2 1/3 package/opengl-registry: new package

Thomas, All,

On 2014-10-05 19:08 +0200, Thomas Petazzoni spake thusly:

Quoted 7 lines

Dear Yann E. MORIN,

Quoted 3 lines · Yann E. MORIN
Quoted 3 lines
Quoted 2 lines

We use the last svn revision at which the api directory was *changed*, not the revision the repository is currently at.

Quoted 8 lines
Quoted 6 lines
Quoted 1 line

Why does this matter?

It does not matter. It is just a note that the revision used might be different than the current revision in the SVN tree, because the tree contains many other things than the registry, some of which are not even public.

Hum, ok. I found it a bit weird.

OK, I rephrased that, and moved it after the --- line.

[--SNIP--]

Quoted 6 lines
Quoted 3 lines
Quoted 1 line

Do we know why this gl.h is not part of the upstream opengl-registry?

No, I have no idea.

Do you know if there's some sort of upstream to which we could report what looks like a "bug" ?

No idea. I'll look on their website. What 'bug' would you want to report? Missing gl.h?

Quoted 2 lines

I was wondering what other distributions do, and seems like Ubuntu is also adding all those headers through a big patch.

Yes, and that's also what the NVidia binary blob suggest. They even have their own gl.h, but they say it is incomplete, and the one from the distribution should be used.

I choose to do what others did, and pick one of the gl.h headers. The one from mesa3d is as good as any other...

Quoted 15 lines
Quoted 11 lines
Quoted 10 lines

package/opengl-registry/Config.in line 18

Quoted 6 lines
package/opengl-registry/Config.in new file +6 -0
+	  This package installs the openGL header files. You do not need them
+	  if the OpenGL/EGL/GLES implementation provides its own headers.
+	  Currently, the only known implementation requiring OpenGL Resgistry
+	  is the NVidia proprietary driver.
+
+	  https://www.opengl.org/registry/

Should we foresee any problem if an OpenGL implementation providing its own header files (e.g rpi-userland, gpu-imx, etc.) gets selected in addition to this package? They will overwrite each other files, no?

Quoted 3 lines

Hmm.. I think I thought about that when I did the patch, I can't remember what I came up with as a conclusion. Lemme think about it once again...

Quoted 5 lines

For safety, should we ensure this package only gets selected together with the NVidia driver? Don't know exactly since we can't have A depends on B, and B select A. Make opengl-registry a blind option, so that people cannot select it, and even autobuilders will not select it, except as a dependency of the NVidia driver package.

I've made opengl-registry a prompt-less package, that nvidia-driver selects. Others may do so if they need to.

Quoted 11 lines
Quoted 5 lines
Quoted 3 lines

Why not simply use a patch instead of this awk magic? We generally use patches when possible. In this case, you're patching only one file, so clearly a patch seems to make sense here, no?

Because it is done after the build, and changs a generated file.

Aaah, yes, indeed. I guess the generation logic is too complicated to be patched. So, we'll have to keep the awk magic. Maybe add a short comment that mentions that it's done after the headers have been generated.

Quoted 4 lines

Also, this is using some Python script to generate the headers. Is this Python script only using the Python standard library for XML, or is it using some external Python library that will cause troubles in terms of Buildroot "core" dependencies?

Indeed, it is using lxml, which is an external Python module. I've added that new package to the series, and made opengl-registry depend on it and on host-python.

Thanks!

Regards,
Yann E. MORIN.

Signature · 6 lines
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
author
#6 lore raw

PATCH v2 2/3 package/nvidia-driver: add NVidia's OpenGL binary blob

In reply to Yann E. MORIN

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.

Signed-off-by "Yann E. MORIN" <[email protected]>
---
 package/Config.in                      |  1 +
 package/nvidia-driver/Config.in        | 64 +++++++++++++++++++++++
 package/nvidia-driver/nvidia-driver.mk | 92 ++++++++++++++++++++++++++++++++++
 3 files changed, 157 insertions(+)
 create mode 100644 package/nvidia-driver/Config.in
 create mode 100644 package/nvidia-driver/nvidia-driver.mk
package/Config.in +1 -0
index 9a81f59..e0b371e 100644
@@ -203,6 +203,7 @@ endif
 	source "package/linux-fusion/Config.in"
 	source "package/lite/Config.in"
 	source "package/mesa3d/Config.in"
+	source "package/nvidia-driver/Config.in"
 	source "package/ocrad/Config.in"
 	source "package/psplash/Config.in"
 	source "package/sawman/Config.in"
package/nvidia-driver/Config.in new file +64 -0

64 lines not on this page · raw message

package/nvidia-driver/nvidia-driver.mk new file +92 -0

92 lines not on this page · raw message

Signature · 1 line
1.9.1
#7 lore raw

PATCH v2 2/3 package/nvidia-driver: add NVidia's OpenGL binary blob

Dear Yann E. MORIN,

package/nvidia-driver/Config.in line 5

Quoted 11 lines · Yann E. MORIN
package/nvidia-driver/Config.in new file +5 -0
new file mode 100644
index 0000000..becb1ae
@@ -0,0 +1,64 @@
+# Note: we only require 'threads', although that might well be NPTL.
+# But we require (e)glibc, which nowadays only has NPTL anyway.
+comment "nvidia-driver needs an (e)glibc toolchain w/ threads"
+	depends on BR2_i386 || BR2_x86_64 || BR2_PACKAGE_NVIDIA_DRIVER_arm_OK
+	depends on !BR2_TOOLCHAIN_USES_GLIBC || !BR2_TOOLCHAIN_HAS_THREADS

Is it possible to have a glibc toolchain without thread support?

package/nvidia-driver/Config.in line 9

Quoted 4 lines
package/nvidia-driver/Config.in new file +4 -0
+
+# Nividia has an ARM driver, but it's only little-endian,
+# armv7 and gnueabihf
+config BR2_PACKAGE_NVIDIA_DRIVER_arm_OK

Capital letters for the entire option.

package/nvidia-driver/Config.in line 16

Quoted 7 lines
package/nvidia-driver/Config.in new file +7 -0
+	bool
+	default y
+	depends on BR2_arm
+	depends on BR2_ARM_EABIHF
+	depends on BR2_cortex_a5 || BR2_cortex_a7 || BR2_cortex_a8 \
+		|| BR2_cortex_a9 || BR2_cortex_a12 || BR2_cortex_a15 \
+		|| BR2_pj4

However, I'm wondering if we should use the more traditional BR2_PACKAGE_NVIDIA_DRIVER_ARCH_SUPPORTS logic. Something like:

config BR2_PACKAGE_NVIDIA_DRIVER_ARCH_SUPPORTS

	bool
	default y if BR2_i386
	default y if BR2_x86_64
	default y if (BR2_arm && BR2_ARM_EABIHF && \
		(BR2_cortex_a5 || BR2_cortex_a7 || ...)

Maybe it's time to introduce some kconfig booleans such as BR2_ARM_ARMV5, BR2_ARM_ARMV6, BR2_ARM_ARMV7, because we're duplicating this BR2_cortexa<foo> logic in multiple places. Not related to this patch, though.

package/nvidia-driver/Config.in line 20

Quoted 4 lines
package/nvidia-driver/Config.in new file +4 -0
+
+config BR2_PACKAGE_NVIDIA_DRIVER
+	bool "nvidia-driver"
+	depends on BR2_i386 || BR2_x86_64 || BR2_PACKAGE_NVIDIA_DRIVER_arm_OK

Would become depends on BR2_PACKAGE_NVIDIA_DRIVER_ARCH_SUPPORTS.

package/nvidia-driver/Config.in line 23

Quoted 3 lines
package/nvidia-driver/Config.in new file +3 -0
+	depends on BR2_TOOLCHAIN_USES_GLIBC
+	depends on BR2_TOOLCHAIN_HAS_THREADS
+	depends on BR2_PACKAGE_XSERVER_XORG_SERVER_MODULAR

Should we have a comment about this? We generally depend on just BR2_PACKAGE_XORG7. But agree it's a bit hard to "select" the modular server.

Quoted 47 lines
package/nvidia-driver/Config.in new file +41 -0
+	select BR2_PACKAGE_OPENGL_REGISTRY
+	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
+	help
+	  The binary-only driver blob for NVidia cards.
+	  This is the userland part only.
+
+	  http://www.nvidia.com/
+
+if BR2_PACKAGE_NVIDIA_DRIVER
+
+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_CUDA
+	bool "CUDA support"
+
+config BR2_PACKAGE_NVIDIA_DRIVER_OPENCL
+	bool "OpenCL support"
+	depends on BR2_PACKAGE_NVIDIA_DRIVER_CUDA
+
+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.
+
+endif # BR2_PACKAGE_NVIDIA_DRIVER
package/nvidia-driver/nvidia-driver.mk new file +0 -0
new file mode 100644
index 0000000..efe3fa0

package/nvidia-driver/nvidia-driver.mk line 10

Quoted 10 lines
package/nvidia-driver/nvidia-driver.mk new file +10 -0
@@ -0,0 +1,92 @@
+################################################################################
+#
+# nvidia-driver
+#
+################################################################################
+
+NVIDIA_DRIVER_VERSION = 340.32
+NVIDIA_DRIVER_SUFFIX = $(if $(BR2_x86_64),_64)
+NVIDIA_DRIVER_SITE = ftp://download.nvidia.com/XFree86/Linux-x86$(NVIDIA_DRIVER_SUFFIX)/$(NVIDIA_DRIVER_VERSION)
+NVIDIA_DRIVER_SOURCE = NVIDIA-Linux-x86$(NVIDIA_DRIVER_SUFFIX)-$(NVIDIA_DRIVER_VERSION).run

Hum, and this works for ARM ? the 'x86' part of the filename would indicate not, but I haven't checked.

package/nvidia-driver/nvidia-driver.mk line 19

Quoted 9 lines
package/nvidia-driver/nvidia-driver.mk new file +9 -0
+NVIDIA_DRIVER_LICENSE = NVIDIA Software License
+NVIDIA_DRIVER_LICENSE_FILES = LICENSE
+NVIDIA_DRIVER_REDISTRIBUTE = NO
+NVIDIA_DRIVER_INSTALL_STAGING = YES
+
+NVIDIA_DRIVER_DEPENDENCIES = opengl-registry xlib_libX11 xlib_libXext
+NVIDIA_DRIVER_PROVIDES = libgl libegl libgles
+
+NVIDIA_DRIVER_LIBS_NO_VERSION =

Not really needed, variables are empty by default.

package/nvidia-driver/nvidia-driver.mk line 24

Quoted 5 lines
package/nvidia-driver/nvidia-driver.mk new file +5 -0
+NVIDIA_DRIVER_LIBS = libEGL libGLESv1_CM libGLESv2 libGL \
+		       libnvidia-glcore libnvidia-eglcore libnvidia-glsi \
+		       tls/libnvidia-tls \
+		       libvdpau libvdpau_nvidia \
+		       libnvidia-ml

Only one tab for the indentation on continuation lines.

package/nvidia-driver/nvidia-driver.mk line 31

Quoted 7 lines
package/nvidia-driver/nvidia-driver.mk new file +7 -0
+
+ifeq ($(BR2_PACKAGE_NVIDIA_DRIVER_CUDA),y)
+NVIDIA_DRIVER_LIBS += libcuda libnvidia-compiler libnvcuvid libnvidia-encode
+endif
+
+ifeq ($(BR2_PACKAGE_NVIDIA_DRIVER_OPENCL),y)
+NVIDIA_DRIVER_LIBS_NO_VERSION += libOpenCL.so.1.0.0

What is special about this one to be marked "NO_VERSION" ?

Quoted 5 lines
package/nvidia-driver/nvidia-driver.mk new file +5 -0
+NVIDIA_DRIVER_LIBS += libnvidia-opencl
+endif
+
+# Those libraries are 'private' libraries requiring an agreement with
+# NVidia to develop code for those libs. There seems to be no restriction

package/nvidia-driver/nvidia-driver.mk line 46

Quoted 10 lines
package/nvidia-driver/nvidia-driver.mk new file +10 -0
+# on using those libraries (e.g. if the user has such an agreement, or
+# wants to run a third-party program developped under such an agreement).
+ifeq ($(BR2_PACKAGE_NVIDIA_DRIVER_PRIVATE_LIBS),y)
+NVIDIA_DRIVER_LIBS += libnvidia-ifr libnvidia-fbc
+endif
+
+# We refer to the destination path; the origin file has no directory component
+NVIDIA_DRIVER_X_MODS = drivers/nvidia_drv.so \
+			 extensions/libglx.so.$(NVIDIA_DRIVER_VERSION) \
+			 libnvidia-wfb.so.$(NVIDIA_DRIVER_VERSION)

Ditto.

package/nvidia-driver/nvidia-driver.mk line 54

Quoted 8 lines
package/nvidia-driver/nvidia-driver.mk new file +8 -0
+
+# The downloaded archive is in fact an auto-extract script. So, it can run
+# virtually everywhere, and it is fine enough to provide useful options.
+# Except it can't extract into an existing (even empty) directory.
+define NVIDIA_DRIVER_EXTRACT_CMDS
+	$(SHELL) $(DL_DIR)/$(NVIDIA_DRIVER_SOURCE) --extract-only --target $(@D)/foo
+	mv $(@D)/foo/* $(@D)/foo/.manifest $(@D)
+	rm -rf $(@D)/foo

Is 'foo' the right temporary name ? :-)

Quoted 9 lines
package/nvidia-driver/nvidia-driver.mk new file +9 -0
+endef
+
+# Helper to install libraries
+# $1: destination directory (target or staging)
+define NVIDIA_DRIVER_INSTALL_LIBS
+	for lib in $(patsubst %,%.so.$(NVIDIA_DRIVER_VERSION),$(NVIDIA_DRIVER_LIBS)) \
+	           $(NVIDIA_DRIVER_LIBS_NO_VERSION); \
+	do \
+		$(INSTALL) -v -D -m 0644 $(@D)/$${lib} $(1)/usr/lib/$${lib##*/}; \

package/nvidia-driver/nvidia-driver.mk line 73

Quoted 10 lines
package/nvidia-driver/nvidia-driver.mk new file +10 -0
+		n="$$( $(TARGET_READELF) -d "$(@D)/$${lib}" \
+		       |sed -r -e '/.*\(SONAME\).*\[(.*)\]$$/!d; s//\1/;' )"; \
+		if [ -n "$${n}" -a "$${n}" != "$${lib##*/}" ]; then \
+			ln -sfv $${lib##*/} $(1)/usr/lib/$${n}; \
+		fi; \
+		n="$${lib##*/}"; n="$${n/.so*}.so"; \
+		if [ -n "$${n}" -a "$${n}" != "$${lib##*/}" ]; then \
+			ln -sfv $${lib##*/} $(1)/usr/lib/$${n}; \
+		fi; \
+	done

Wow. This is a *lot* of $ and # signs. Do we really need to do all that stuff, looking at the SONAME and so on?

At the very least, some comments would be good to have. But a simpler solution would be even better :-)

package/nvidia-driver/nvidia-driver.mk line 79

Quoted 6 lines
package/nvidia-driver/nvidia-driver.mk new file +6 -0
+endef
+
+# For staging, install libraries and development files
+define NVIDIA_DRIVER_INSTALL_STAGING_CMDS
+	$(call NVIDIA_DRIVER_INSTALL_LIBS,$(STAGING_DIR))
+	$(INSTALL) -v -D -m 0644 $(@D)/libGL.la $(STAGING_DIR)/usr/lib/libGL.la

Why -v ?

package/nvidia-driver/nvidia-driver.mk line 80

Quoted 1 line
package/nvidia-driver/nvidia-driver.mk new file +1 -0
+	$(SED) 's/-L[^[:space:]]\+//' $(STAGING_DIR)/usr/lib/libGL.la

Do we really need to install the .la file here?

package/nvidia-driver/nvidia-driver.mk line 88

Quoted 8 lines
package/nvidia-driver/nvidia-driver.mk new file +8 -0
+endef
+
+# For target, install libraries and X.org modules
+define NVIDIA_DRIVER_INSTALL_TARGET_CMDS
+	$(call NVIDIA_DRIVER_INSTALL_LIBS,$(TARGET_DIR))
+	for m in $(NVIDIA_DRIVER_X_MODS); do \
+		 $(INSTALL) -v -D -m 0644 $(@D)/$${m##*/} \
+					  $(TARGET_DIR)/usr/lib/xorg/modules/$${m}; \

Less indentation for the continuation line, and no -v option for $(INSTALL).

Thanks,

Thomas

Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
author
#8 lore raw

PATCH v2 2/3 package/nvidia-driver: add NVidia's OpenGL binary blob

Thomas, All,

On 2014-10-05 18:59 +0200, Thomas Petazzoni spake thusly:

Quoted 6 lines · Yann E. MORIN
Quoted 5 lines
package/nvidia-driver/Config.in new file +0 -0
new file mode 100644
index 0000000..becb1ae
Quoted 8 lines

package/nvidia-driver/Config.in line 5

Quoted 6 lines
package/nvidia-driver/Config.in new file +5 -0
@@ -0,0 +1,64 @@
+# Note: we only require 'threads', although that might well be NPTL.
+# But we require (e)glibc, which nowadays only has NPTL anyway.
+comment "nvidia-driver needs an (e)glibc toolchain w/ threads"
+	depends on BR2_i386 || BR2_x86_64 || BR2_PACKAGE_NVIDIA_DRIVER_arm_OK
+	depends on !BR2_TOOLCHAIN_USES_GLIBC || !BR2_TOOLCHAIN_HAS_THREADS

Is it possible to have a glibc toolchain without thread support?

No, it's not. I've removed that depndency on threads.

Quoted 6 lines

package/nvidia-driver/Config.in line 9

Quoted 3 lines
package/nvidia-driver/Config.in new file +3 -0
+# Nividia has an ARM driver, but it's only little-endian,
+# armv7 and gnueabihf
+config BR2_PACKAGE_NVIDIA_DRIVER_arm_OK

Capital letters for the entire option.

Quoted 10 lines

package/nvidia-driver/Config.in line 16

Quoted 7 lines
package/nvidia-driver/Config.in new file +7 -0
+	bool
+	default y
+	depends on BR2_arm
+	depends on BR2_ARM_EABIHF
+	depends on BR2_cortex_a5 || BR2_cortex_a7 || BR2_cortex_a8 \
+		|| BR2_cortex_a9 || BR2_cortex_a12 || BR2_cortex_a15 \
+		|| BR2_pj4

However, I'm wondering if we should use the more traditional BR2_PACKAGE_NVIDIA_DRIVER_ARCH_SUPPORTS logic. Something like:

[--SNIP--]

Well, see below, I'm ditching ARM support [0]...

Quoted 4 lines

Maybe it's time to introduce some kconfig booleans such as BR2_ARM_ARMV5, BR2_ARM_ARMV6, BR2_ARM_ARMV7, because we're duplicating this BR2_cortexa<foo> logic in multiple places. Not related to this patch, though.

I'll see to do such a patch, but later.

[--SNIP--]

Quoted 7 lines

package/nvidia-driver/Config.in line 23

Quoted 3 lines
package/nvidia-driver/Config.in new file +3 -0
+	depends on BR2_TOOLCHAIN_USES_GLIBC
+	depends on BR2_TOOLCHAIN_HAS_THREADS
+	depends on BR2_PACKAGE_XSERVER_XORG_SERVER_MODULAR

Should we have a comment about this? We generally depend on just BR2_PACKAGE_XORG7. But agree it's a bit hard to "select" the modular server.

OK, I will add it.

But we do not usually provide such a comment (if what you meant was a kconfig-comment).

[--SNIP--]

Quoted 11 lines
Quoted 11 lines
package/nvidia-driver/nvidia-driver.mk new file +5 -0
new file mode 100644
index 0000000..efe3fa0
@@ -0,0 +1,92 @@
+################################################################################
+#
+# nvidia-driver
+#
+################################################################################
Quoted 8 lines

package/nvidia-driver/nvidia-driver.mk line 10

Quoted 5 lines
package/nvidia-driver/nvidia-driver.mk new file +5 -0
+
+NVIDIA_DRIVER_VERSION = 340.32
+NVIDIA_DRIVER_SUFFIX = $(if $(BR2_x86_64),_64)
+NVIDIA_DRIVER_SITE = ftp://download.nvidia.com/XFree86/Linux-x86$(NVIDIA_DRIVER_SUFFIX)/$(NVIDIA_DRIVER_VERSION)
+NVIDIA_DRIVER_SOURCE = NVIDIA-Linux-x86$(NVIDIA_DRIVER_SUFFIX)-$(NVIDIA_DRIVER_VERSION).run

Hum, and this works for ARM ? the 'x86' part of the filename would indicate not, but I haven't checked.

Hehe... :-)

[0] I think I'll just ditch ARM support, because I'm not able to test it. It will always be time to add it back later, when/if someone is interested.

[--SNIP--]

Quoted 2 lines

package/nvidia-driver/nvidia-driver.mk line 19

Quoted 1 line
package/nvidia-driver/nvidia-driver.mk new file +1 -0
+NVIDIA_DRIVER_LIBS_NO_VERSION =

Not really needed, variables are empty by default.

OK.

Quoted 6 lines

package/nvidia-driver/nvidia-driver.mk line 24

Quoted 5 lines
package/nvidia-driver/nvidia-driver.mk new file +5 -0
+NVIDIA_DRIVER_LIBS = libEGL libGLESv1_CM libGLESv2 libGL \
+		       libnvidia-glcore libnvidia-eglcore libnvidia-glsi \
+		       tls/libnvidia-tls \
+		       libvdpau libvdpau_nvidia \
+		       libnvidia-ml

Only one tab for the indentation on continuation lines.

OK.

Quoted 8 lines

package/nvidia-driver/nvidia-driver.mk line 31

Quoted 6 lines
package/nvidia-driver/nvidia-driver.mk new file +6 -0
+ifeq ($(BR2_PACKAGE_NVIDIA_DRIVER_CUDA),y)
+NVIDIA_DRIVER_LIBS += libcuda libnvidia-compiler libnvcuvid libnvidia-encode
+endif
+
+ifeq ($(BR2_PACKAGE_NVIDIA_DRIVER_OPENCL),y)
+NVIDIA_DRIVER_LIBS_NO_VERSION += libOpenCL.so.1.0.0

What is special about this one to be marked "NO_VERSION" ?

Instead of repeating the $(NVIDIA_DRIVER_VERSION) for each and every libraries, NVIDIA_DRIVER_LIBS only contains the base name of the library, and I append the version string in a single place [1].

Unfortunately a single library does not have the NVidia version string, so I need to treat it differently [1].

Quoted 8 lines
Quoted 8 lines
package/nvidia-driver/nvidia-driver.mk new file +8 -0
+NVIDIA_DRIVER_LIBS += libnvidia-opencl
+endif
+
+# Those libraries are 'private' libraries requiring an agreement with
+# NVidia to develop code for those libs. There seems to be no restriction
+# on using those libraries (e.g. if the user has such an agreement, or
+# wants to run a third-party program developped under such an agreement).
+ifeq ($(BR2_PACKAGE_NVIDIA_DRIVER_PRIVATE_LIBS),y)
Quoted 8 lines

package/nvidia-driver/nvidia-driver.mk line 46

Quoted 7 lines
package/nvidia-driver/nvidia-driver.mk new file +7 -0
+NVIDIA_DRIVER_LIBS += libnvidia-ifr libnvidia-fbc
+endif
+
+# We refer to the destination path; the origin file has no directory component
+NVIDIA_DRIVER_X_MODS = drivers/nvidia_drv.so \
+			 extensions/libglx.so.$(NVIDIA_DRIVER_VERSION) \
+			 libnvidia-wfb.so.$(NVIDIA_DRIVER_VERSION)

Ditto.

Ditto what?

They are Xorg drivers, not traditional libraries. They go to specific places.

Quoted 8 lines

package/nvidia-driver/nvidia-driver.mk line 54

Quoted 7 lines
package/nvidia-driver/nvidia-driver.mk new file +7 -0
+# The downloaded archive is in fact an auto-extract script. So, it can run
+# virtually everywhere, and it is fine enough to provide useful options.
+# Except it can't extract into an existing (even empty) directory.
+define NVIDIA_DRIVER_EXTRACT_CMDS
+	$(SHELL) $(DL_DIR)/$(NVIDIA_DRIVER_SOURCE) --extract-only --target $(@D)/foo
+	mv $(@D)/foo/* $(@D)/foo/.manifest $(@D)
+	rm -rf $(@D)/foo

Is 'foo' the right temporary name ? :-)

If that can make you happier, I'll rename. :-)

Quoted 7 lines

package/nvidia-driver/nvidia-driver.mk line 61

Quoted 7 lines
package/nvidia-driver/nvidia-driver.mk new file +7 -0
+endef
+
+# Helper to install libraries
+# $1: destination directory (target or staging)
+define NVIDIA_DRIVER_INSTALL_LIBS
+	for lib in $(patsubst %,%.so.$(NVIDIA_DRIVER_VERSION),$(NVIDIA_DRIVER_LIBS)) \
+	           $(NVIDIA_DRIVER_LIBS_NO_VERSION); \

[1] here.

Quoted 7 lines
Quoted 7 lines
package/nvidia-driver/nvidia-driver.mk new file +7 -0
+	do \
+		$(INSTALL) -v -D -m 0644 $(@D)/$${lib} $(1)/usr/lib/$${lib##*/}; \
+		n="$$( $(TARGET_READELF) -d "$(@D)/$${lib}" \
+		       |sed -r -e '/.*\(SONAME\).*\[(.*)\]$$/!d; s//\1/;' )"; \
+		if [ -n "$${n}" -a "$${n}" != "$${lib##*/}" ]; then \
+			ln -sfv $${lib##*/} $(1)/usr/lib/$${n}; \
+		fi; \
Quoted 8 lines

package/nvidia-driver/nvidia-driver.mk line 73

Quoted 5 lines
package/nvidia-driver/nvidia-driver.mk new file +5 -0
+		n="$${lib##*/}"; n="$${n/.so*}.so"; \
+		if [ -n "$${n}" -a "$${n}" != "$${lib##*/}" ]; then \
+			ln -sfv $${lib##*/} $(1)/usr/lib/$${n}; \
+		fi; \
+	done

Wow. This is a *lot* of $ and # signs. Do we really need to do all that stuff, looking at the SONAME and so on?

Ah! Glad you asked! :-)

Take this library for example: libnvidia-opencl.so.340.46. Its SONAME is in fact libnvidia-opencl.so.1 so we need it to be named like that on the target, or it would fail at run time.

Also, we need the short symlink, or we can't link at build time.

Quoted 2 lines

At the very least, some comments would be good to have. But a simpler solution would be even better :-)

I'll see what I can do. Probably, add a big fat comment explaining what's going on. My bad, I was all too hapy to submit this patch, which took quite some work already. And takes even some more yet again. :-)

Quoted 7 lines

package/nvidia-driver/nvidia-driver.mk line 79

Quoted 6 lines
package/nvidia-driver/nvidia-driver.mk new file +6 -0
+endef
+
+# For staging, install libraries and development files
+define NVIDIA_DRIVER_INSTALL_STAGING_CMDS
+	$(call NVIDIA_DRIVER_INSTALL_LIBS,$(STAGING_DIR))
+	$(INSTALL) -v -D -m 0644 $(@D)/libGL.la $(STAGING_DIR)/usr/lib/libGL.la

Why -v ?

Leffover debug stuff.

Quoted 2 lines

package/nvidia-driver/nvidia-driver.mk line 80

Quoted 1 line
package/nvidia-driver/nvidia-driver.mk new file +1 -0
+	$(SED) 's/-L[^[:space:]]\+//' $(STAGING_DIR)/usr/lib/libGL.la

Do we really need to install the .la file here?

Yes, it is needed (can't remember why, I added it because something else failed to build).

Quoted 11 lines

package/nvidia-driver/nvidia-driver.mk line 88

Quoted 8 lines
package/nvidia-driver/nvidia-driver.mk new file +8 -0
+endef
+
+# For target, install libraries and X.org modules
+define NVIDIA_DRIVER_INSTALL_TARGET_CMDS
+	$(call NVIDIA_DRIVER_INSTALL_LIBS,$(TARGET_DIR))
+	for m in $(NVIDIA_DRIVER_X_MODS); do \
+		 $(INSTALL) -v -D -m 0644 $(@D)/$${m##*/} \
+					  $(TARGET_DIR)/usr/lib/xorg/modules/$${m}; \

Less indentation for the continuation line, and no -v option for $(INSTALL).

OK. Ditto, debug stuff.

Thank you! :-)

Regards,
Yann E. MORIN.

Signature · 6 lines
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
author
#9 lore raw

PATCH v2 3/3 package/nvidia-driver: build the kernel module

In reply to Yann E. MORIN

Add option to build the nvidia.ko module. If CUDA is enabled, 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
Signed-off-by "Yann E. MORIN" <[email protected]>
---
 package/nvidia-driver/Config.in        | 13 +++++++++
 package/nvidia-driver/nvidia-driver.mk | 49 ++++++++++++++++++++++++++++++++++
 2 files changed, 62 insertions(+)
package/nvidia-driver/Config.in +13 -0
index becb1ae..fd5dfeb 100644
@@ -61,4 +61,17 @@ config BR2_PACKAGE_NVIDIA_DRIVER_PRIVATE_LIBS
 	  Say 'y' here if you plan on running a program that uses those
 	  private libraries.
 
+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
+	help
+	  Build the nvidia.ko kernel module.
+
+	  If CUDA support (above) is set, 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.
+
 endif # BR2_PACKAGE_NVIDIA_DRIVER
package/nvidia-driver/nvidia-driver.mk +49 -0

61 lines not on this page · raw message

Signature · 1 line
1.9.1
#10 lore raw

PATCH v2 3/3 package/nvidia-driver: build the kernel module

Dear Yann E. MORIN,

Quoted 4 lines · Yann E. MORIN

Add option to build the nvidia.ko module. If CUDA is enabled, also build the nvidia-uvm.ko kernel module (for Unified Memory access), which is required by the CUDA user-land library.

Quoted 8 lines

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
Signed-off-by "Yann E. MORIN" <[email protected]>
---
 package/nvidia-driver/Config.in        | 13 +++++++++
 package/nvidia-driver/nvidia-driver.mk | 49 ++++++++++++++++++++++++++++++++++
 2 files changed, 62 insertions(+)

This one looks fine to me, so:

Reviewed-by Thomas Petazzoni <[email protected]>

Thomas

Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com