No, that's a copyright violation, and it won't run on AMD or Intel GPUs, or kernels with a different Nvidia driver version.

▲

amelius 11 hours ago | parent [-]

But this ruins the entire idea of packaging software in a self-contained way, at least for a large class of programs.

It makes me wonder, does the OS still take its job of hardware abstraction seriously these days?

▲

holowoodman 11 hours ago | parent | next [-]

The OS does. Nvidia doesn't.

▲

direwolf20 10 hours ago | parent [-]

Does Nvidia not support OpenGL?

▲

holowoodman 10 hours ago | parent [-]

Not really. Nvidia-OpenGL is incompatible to all existing OS OpenGL interfaces, so you need to ship a separate libGL.so if you want to run on Nvidia. In some cases you even need separate binaries, because if you dynamically link against Nvidia's libGL.so, it won't run with any other libGL.so. Sometimes also vice versa.

▲

9 hours ago | parent | next [-]

[deleted]

▲

direwolf20 9 hours ago | parent | prev [-]

Does AMD use a statically linked OpenGL?

▲

holowoodman 9 hours ago | parent [-]

AMD uses the dynamically linked system libGL.so, usually Mesa.

▲

direwolf20 6 hours ago | parent [-]

So you still need dynamic linking to load the right driver for your graphics card.

	▲	holowoodman 6 hours ago \| parent [-]
		Most stuff like that uses some kind of "icd" mechanism that does 'dlopen' on the vendor-specific parts of the library. Afaik neither OpenGL nor Vulkan nor OpenCL are usable without at least dlopen, if not full dynamic linking.

▲

direwolf20 10 hours ago | parent | prev | next [-]

It does, and one way it does that is by dynamically loading the right driver code for your hardware.

▲

maccard 9 hours ago | parent | prev [-]

That’s a licensing problem not a packaging problem. A DLL is a DLL - only thing that changes is whether you’re allowed redistribute it