## Another way to assess quickly, how many computing cores our GPU has.

This posting is on a familiar topic.

On certain Windows computers, there was a popular GUI-based tool named “CPU-Z”, which would give the user fast info about the capabilities of his CPU. Well that application inspired many others, on different platforms, among them, “CUDA-Z”, available for Linux.

If the user has CUDA installed, then he can Download this tool from SourceForge, which is available under Linux as an executable, which can just be put into any directory and run from there. This type of statically-linked executable has come to be known as ‘an app-image’ in the Linux world, but in this case the filename ends with ‘.run’. Below is what mine shows me… Its permission-bits need to be changed to ‘a+x’ after downloading:

I find almost all the information accurate, the only exception being the “Runtime Dll Version”. BTW, Linux computers don’t generally have DLL Files. But I expect that this version-number stems from some internal limitation of the app, as I already know that my Run-Time Version is 8.0.44 .

Dirk

## 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…

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

## Kernel Update today, Downtime, Multiple Reboot-Attempts

Today, the PC which is hosting my site and blog, which I name ‘Phoenix’, received a kernel update.

Debian Team has not been following standard guidelines in their propagation of kernel updates, as the last 3 updates produced the same kernel-version number:


3.16.0-6-amd64



Because even Linux computers require a reboot after a kernel-update, this blog was temporarily off-line from about 13h05 until 13h25. I apologize for any inconvenience to my readers.

There is a fact about the build of Linux on this computer which I should bring up. I have the following on-board graphics-chip:


GeForce 6150SE nForce 430/integrated/SSE2



And this proprietary graphics driver is the only one, capable of working with the said graphics-chip:


NVIDIA 304.137



The graphics driver is installed from standard Debian repositories.

Somewhere between these software-packages there is a problem, which Debian Team has never been aware of, but which has existed ever since I installed Debian / Jessie on this computer. Directly after a reboot, the ability of the X-server to start, is not reliable. Sometimes, the X-server starts on the first try, but on other occasions I need to make 7 reboot attempts, before the X-server will start, and from one reboot-attempt to the next, I change nothing.

Once the X-server has started successfully, this graphics-chip will work 100% for 30 days !

I have been reluctant to point this out for the past few years, because if a Debian developer finds out about it, he will try to fix this problem. And when he does, he will brick my computer.

This afternoon, 7 reboots were in fact required, before the X-server started. That is why the reboot-procedure took 20 minutes of time.

(Updated 07/14/2018, 16h45 … )

## Another Caveat, To GPU-Computing

I had written in previous postings, that I had replaced the ‘Nouveau’ graphics-drivers, that are open-source, with proprietary ‘nVidia’ drivers, that offer more capabilities, on the computer which I name ‘Plato’. In this previous posting, I described a bug that had developed between these recent graphics-drivers, and ‘xscreensaver’.

Well there is more, that can go wrong between the CPU and the GPU of a computer, if the computer is operating a considerable GPU.

When applications set up ‘rendering pipelines’ – aka contexts – they are loading data-structures as well as register-values, onto the graphics card and onto its graphics memory. Well, if the application, that would according to older standards only have resided in system memory, either crashes, or gets forcibly closed using a ‘kill -9′ instruction, then the kernel and the graphics driver will fail to clean up, whatever data-structures it had set up on the graphics card.

The ideal behavior would be, that if an application crashes, the kernel not only clean up whatever resources it was using in system memory, and within the O/S, but also, belonging to graphics memory. And for all I know, the programmers of the open-source drivers under Linux may have made this a top priority. But apparently, nVidia did not.

And so a scenario which can take place, is that the user needs to kill a hung application that was making heavy use of the graphics card, and that afterward, the state of the graphics card is corrupted, so that for example, ‘OpenCL‘ kernels will no longer run on it correctly.