Yesterday evening, a major software update was received to the computer which I name ‘Phosphene’, putting its Debian version to 9.9 from 9.8. One of the main features of the update was, an update to the NVIDIA graphics drivers, as installed from the standard Debian repositories, to version 390.116.
This allows the maximum OpenGL version supported by the drivers to be 4.6.0, and for the first time, I’m noticing that my hardware now limits me to OpenGL 4.5 .
The new driver version does not come with an update to the CUDA version, the latter of which merits some comment. When users install CUDA to Debian / Stretch from the repositories, they obtain run-time version 8.0.44, even though the newly-updated drivers support CUDA all the way up to version 9. This is a shame because CUDA 8.0 cannot be linked to, when compiling code on the GCC / CPP / C++ 6 framework, that is also standard for Debian Stretch. When we want code to run on the GPGPU, we can just load the code onto the GPU using the CUDA run-time v8.0.44, and it runs fine. But if we want to compile major software against the headers, we are locked out. The current Compiler version is too high, for this older CUDA Run-Time version. (:1) (:4)
But on the other side of this irony, I just performed an extension of my own by installing ‘ArrayFire‘ v3.6.3 , coincidentally directly after this update. And my first attempt to do so involved the binary installer that ships with its own CUDA run-time libraries, those being of version 10. Guess what, Driver version 390 is still not high enough to accommodate Run-Time version 10. This resulted in a confusing error message at first, stating that the driver was not high enough, apparently to accommodate the run-time
installed system-wide, which would have been bad news for me, as it would have meant a deeply misconfigured setup – and a newly-botched update. It was only after learning that the binary installer for ArrayFire ships with its own CUDA run-time, that I was relieved to know that the system-installed run-time, was fine…
(Updated 4/29/2019, 20h20 … )
(As of 7h45 : )
But as punishment for the insolence that the binary installer for ArrayFire had demonstrated, I reminded myself of how easy it can sometimes be, for 3rd-party software to corrupt system software, especially by confusing the user about what the exact state of his system is. And so, I next uninstalled the version of ArrayFire that I had just installed, from the ‘
/opt‘ directory and from the ‘
/etc/ld.so.conf.d‘ directory, and installed a different version of the same software (a variant of v3.7.0) (:2), that stems from a custom-compile (to the prefix ‘
/usr/local‘). And because it would remain impossible for me to have compiled that against my CUDA run-time, I disabled this feature within ‘cmake-gui’, so that my custom-compiled ArrayFire version no longer offers it. Now my ArrayFire only offers CPU-based and OpenCL-based computing, as well as graphics through ‘Forge’. (:3) And all the demos I’ve tried finally run fine.
I suppose that when Debian Maintainers compile packages that do depend on CUDA, they use a cropped-back version of the GCC and CPP compilers, of which version 5.3 will work. But it’s not practical and safe – for me to, have that old set of compilers co-installed with the main ones.
I can’t even compile GCC v5.3 .
If a Debian / Stretch user has installed his CUDA Toolkit from the package repositories, then he will have the following folder:
And within that folder there will be – among others – the following two executable files: ‘
g++‘ and ‘
gcc‘. Those are not symlinks, and I’m sure that both work. When given small GPU computing projects, those compilers may be all that’s needed, and theoretically, that folder can also be prepended to the ‘PATH’ variable. But for medium to large projects, the files in that folder are not enough.
Further, when I was compiling ‘Forge’ separately from within its own folder, I made the following observations. Within ‘cmake-gui’, I needed to uncheck ‘
FG_BUILD_CUDA_EXAMPLES‘, and needed to set ‘
CMAKE_BUILD_TYPE‘ to ‘Release’. Then, after CMake had generated the Makefiles, I needed to navigate into the following folder:
Within that directory, two auto-generated files needed editing: ‘
build.make‘ and ‘
A line close to line 1005 in the first of these files pointed to a file that was explicitly to be named ‘…NOTFOUND’. The entry in question needed to be changed, using a text editor, to ‘
The corresponding bogus entry in the second file also needed to be changed, in the same way.
Apparently, the CMake configuration utility has problems locating the ‘FreeType 2′ libraries.
The way to download the latest, bleeding-edge version is like this:
git clone --recursive https://github.com/arrayfire/arrayfire.git (...) cd arrayfire mkdir build cd build cmake-gui
There is a detail worth mentioning, about using OpenCL as a computing back-end. If the host system happens to have a Radeon Graphics Card and an AMD CPU, then the OpenCL devices list will include both. But if the host system has an NVIDIA Graphics Card, and an Intel CPU, the Intel CPU will not be included as an available OpenCL device.
(Update 4/29/2019, 20h20 : )
Admittedly, Linux users are generally offered a solution to this type of ‘version mismatch dilemma’. Instead of limiting themselves to the packages from the standard Debian repositories, they can download a binary installer directly from NVIDIA, with their choice in combination of Graphics Driver / CUDA Run-Time versions, which by now support current GNU GCC and C++ versions. And then, the user may as well go whole-hog, with CUDA RT 10…
I have a personal dislike for that approach, which is based on the fact that the Debian repositories contain numerous packages that are either applications or just back-ends to applications, which depend on the offered packages, providing the CUDA RT. In other words, one way or another, Package Maintainers are able to compile certain packages and link them to the packaged CUDA RT and -Tool-Kit. If I was to install all that from a separate Binary Installer, then the assumption would also be that I’d uninstall the packages, to avoid conflicts. And so doing, I’d be left with no way to resolve those Debian dependencies. Certain existing, Open-Source packages which I presently have installed would become unavailable to me.
And so I go the safe route.