ArrayFire 3.5.1 Compiled, using GCC 4.9.2 and CUDA – Success!

A project which has fixated me for several days has been, to get the API which is named “ArrayFire” custom-compiled, specifically version 3.5.1 of that API, to enable CUDA support. This poses a special problem because when we use the Debian / Stretch repositories to install the CUDA Run-Time, we are limited to installing version 8.0.44. This run-time is too old, to be compatible with the standard GCC / CPP / C++ compiler-set available under the same distribution of Linux. Therefore, it can be hard for users and Debian Maintainers alike to build projects that use CUDA, and which are compatible with -Stretch.

Why use ArrayFire? Because writing kernels for parallel computing on the GPU is hard. ArrayFire is supposed to make the idea more-accessible to people like me, who have no specific training in writing highly parallel code.

When we install ArrayFire from the repositories, OpenCL support is provided, but not CUDA support.

I’ve hatched a plan by which I can install an alternative compiler set on the computer I name ‘Phosphene’, that being GCC / CPP / C++ version 4.9.2, and with which I can switch my compilers to that version, so that maybe, I can compile projects in the future, that do use CUDA, and that are sophisticated enough to require a full compiler-suite to build.

What I’ve found was that contrarily to how it went the previous time, this time I’ve scored a success. :-)  Not only did the project compile without errors, but then, a specific Demo that ships with the source-code version, that uses the ability of CUDA to pass graphics to the OpenGL rendering of the GPU, also ran without errors…

Screenshot_20190501_160413

So now I can be sure that the tool-chain which I’ve installed, is up to the task of compiling highly-complex CUDA projects.

(Update 5/03/2019, 7h30 : )

Continue reading ArrayFire 3.5.1 Compiled, using GCC 4.9.2 and CUDA – Success!

ArrayFire 3.5.1 Compiled, using GCC 4.8.4 and CUDA – Failure!

In this earlier posting I had written, that I had installed GCC / CPP / C++ 4.8.4, alongside versions 6.3, on my computer named ‘Phosphene’, even though Debian / Stretch computers are not meant by design, to offer earlier versions of those compilers. And I had done so, specifically so that I’d be able to compile CUDA 8 projects, for which GCC version 6 is too high.

One possible CUDA project would have been ArrayFire 3.7.0, or version 3.6.3 of that same library. However, what I found was that these latest versions of ArrayFire require a stronger compiler, than v4.8.

Well what I have now been able to do is, to compile ArrayFire 3.5.1 using the GCC 4.8.4 tool-chain, and to do so, even with CUDA support. This is higher than what Debian Maintainers could do, if only because the package-repository version of ArrayFire do not include CUDA back-ends, only OpenCL back-ends.

This proves that my GCC 4.8.4, compatibility tool-chain is correctly installed.

The question which I must now ponder is, whether I should next install v3.5.1 of ArrayFire to my root file-system, replacing v3.7.0, just because the lower version gives me CUDA support. I might not because v3.7.0 already gives me OpenCL support. Either way, I built v3.5.1 with the configuration option, to ‘Use System Forge’, which may mean that I won’t need to recompile Forge, which was compiled as version 1.0.4, and as belonging to ArrayFire 3.7.0.

Installing v3.5.1 to my root file-system would be a necessary step, to verify whether the Demos actually run, since all ArrayFire Demos need to be linked to the same library-versions that their ArrayFire build generated.

(Update:)

What I have found is twofold:

  1. The Configuration option ‘Use System Forge’ will not work, when the installed version of Forge is 1.0.4. This needs to be unchecked, and the integrated version of Forge built, and installed, and
  2. Even though the exercise compiled, it will not run.

When trying to run a CUDA executable, I get the error message:

 


terminate called after throwing an instance of 'std::regex_error'
  what():  regex_error
Aborted

 

What this result means is that I have not been able to confirm that compiling and linking projects to CUDA finally works, using the platform I’ve created, even though the actual compilation produces no error message.

Dirk

 

Compatibility GCC Installed

One of the more frustrating facts about Debian / Stretch is that its maintainers have broken with tradition, by no longer providing any compatibility versions of the main compilers, GCC, CPP and C++, which provide CC and C++ -language support, useful in 90% (+) of all programming that takes place. Instead, Debian / Stretch provides GCC / CPP / C++ version 6.3 alone. What I had already written about was, that the version of the CUDA Run-Time and Toolkit available from the standard repositories, has remained v8.0.44 for the time being. This CUDA Version does not support CC or C++ version 6 because version 6 of these compilers is too high!

One way in which power-users could try to remedy this situation would be, to install some sort of compatibility version of CC / C++, even though none is offered in the standard repositories. But, when we try to custom-compile let’s say, GCC v5.3, which would already be low enough for CUDA 8.0.44 to support, we find that GCC 6.3 is just plain unable to compile GCC 5.3, no matter what.

And so another way to solve the same problem can be, to add the old Debian Jessie / Oldstable repositories to our sources list, and then just to install from there.

I find this to be an extremely bad idea.

First of all, Debian differs from Ubuntu, in that Debian never provided GCC 5.3. In Debian / Jessie, what we got was GCC 4.8, or maybe even v4.9. But more importantly, simply sandwiching two incompatible repositories together can create a fatal set of problems.

What I was finally able to do, was just to download roughly a dozen packages as binaries, from the Debian Repository Web-site, which finally provided GCC, CPP and C++ v4.8. The path I took required that I run into the error message numerous times that dependencies could not be satisfied, because under Debian, neither ‘/usr/bin/gcc’ nor ‘/usr/bin/c++’ are provided by a single, binary package. Each is provided by packages, that depend uniquely on other packages, that are also not in the repositories.

Further, once the power-user has in fact installed binaries, after making sure that none of their file-names overlap, he must also create a system of Debian Alternatives, that allow him to switch between compilers easily. The problem with that is the fact that because, under Debian / Stretch, no provision was ever made by Package Maintainers for alternatives to exist, automatic mechanisms have also not been provided, to install ‘Link Groups’. The Link Groups ‘cc’, ‘cpp’ and ‘c++’ exist, but only in such a way as to provide one executable each.

As I was doing my best to install the Link Groups, I made a mistake, which simply over-wrote ‘/usr/bin/gcc’ with a different symlink, and which therefore forced me to (1) delete the link-group, and (2) reinstall GCC 6.3 from the package manager. After that, a new attempt to set up the link-groups succeeded:

 


dirk@Phosphene:~$ su
Password: 
root@Phosphene:/home/dirk# update-alternatives --config cc
There are 2 choices for the alternative cc (providing /usr/bin/cc).

  Selection    Path              Priority   Status
------------------------------------------------------------
* 0            /usr/bin/gcc-6     20        auto mode
  1            /usr/bin/gcc-4.8   10        manual mode
  2            /usr/bin/gcc-6     20        manual mode

Press  to keep the current choice[*], or type selection number: 
root@Phosphene:/home/dirk# update-alternatives --config cpp
There are 2 choices for the alternative cpp (providing /usr/bin/cpp).

  Selection    Path              Priority   Status
------------------------------------------------------------
* 0            /usr/bin/cpp-6     20        auto mode
  1            /usr/bin/cpp-4.8   10        manual mode
  2            /usr/bin/cpp-6     20        manual mode

Press  to keep the current choice[*], or type selection number: 
root@Phosphene:/home/dirk# update-alternatives --config c++
There are 2 choices for the alternative c++ (providing /usr/bin/c++).

  Selection    Path              Priority   Status
------------------------------------------------------------
* 0            /usr/bin/g++-6     20        auto mode
  1            /usr/bin/g++-4.8   10        manual mode
  2            /usr/bin/g++-6     20        manual mode

Press  to keep the current choice[*], or type selection number: 
root@Phosphene:/home/dirk# exit
exit
dirk@Phosphene:~$ 

 

Note: The first link above, named ‘cc’, has a corresponding slave-link named ‘gcc’, thereby forming the only real ‘Link Group’. The others are just plain Links.

I am reasonably certain that none of these link-groups are broken. But what my reader should be able to infer from what I’ve written, is that It would be a hare-brained attempt, to duplicate what I’ve done, entirely based on this blog posting.

(Edit 5/03/2019, 11h45 : )

Just to prove how hare-brained this idea really is, I just uninstalled the alternative compilers, and replaced them with the GCC / CPP / C++ tool-chain, version 4.9, and made that part of the update-alternatives system as above! :-) (:3)

(End of Edit.)

So what does this provide me with (hopefully)?

(Updated 5/02/2019, 12h15 … )

Continue reading Compatibility GCC Installed

Update to Computer Phosphene Last Night

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…

Screenshot_20190429_104916

(Updated 4/29/2019, 20h20 … )

Continue reading Update to Computer Phosphene Last Night