NVS 510 card: GPU not supported in 415.27 driver?

I’m playing around with Meshroom graphics software on a FC29 system, when I noticed that the GPU of my NVS 510 card (with 192 cores) doesn’t seem to be supported using the 415.27 driver.

nvidia-smi shows Cuda 10 is there. I read at https://devtalk.nvidia.com/default/topic/1045033/linux/cuda-on-fedora-29/ (about a different problem ) that a re-install of Xorg server may be necessary, but re-installing both Xorg server and the driver made no difference.

Am I missing something about the GPU not being supported on this card?

[root@localhost ]# nvidia-smi
Mon Jan 28 15:53:15 2019
| NVIDIA-SMI 415.27       Driver Version: 415.27       CUDA Version: 10.0     |
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|   0  NVS 510             Off  | 00000000:01:00.0 N/A |                  N/A |
| 34%   61C    P0    N/A /  N/A |    474MiB /  1996MiB |     N/A      Default |

| Processes:                                                       GPU Memory |
|  GPU       PID   Type   Process name                             Usage      |
|    0                    Not Supported                                       |

Now, slightly more confusing, I found that nVidia Xerver Settings reports the GPU being present (and in use).

So, is nvidia-smi reporting “Video Engine Utilization” as being zero rather than GPU Utilization?


‘Not Supported’ in the process list just means that listing the running processes is not supported by your GPU, it’s a feature for higher class gpus. The gpu itself is very well supported by the driver, otherwise nvidia-smi would display nothing.

@generix: Thank you for your reply.

As I was digging deeper into the problem last night, I re-installed the CUDA 10 libraries from the runfile (with and without using the “–override” option) and tried to compile the application from scratch. What I learned (from https://docs.nvidia.com/cuda/cuda-installation-guide-linux/index.html) is something that “deep down, in places you don’t want to talk about at parties” (to paraphrase a line from a movie), there is what I consider to be an ugly secret in the fact that CUDA 10 is only supported on FC27 and/or Ubuntu 18.04, which use the GCC 7.x compiler, while FC28 and FC29 use GCC 8.x with no fallback to GCC 7.x (FC30 will be on GCC 9.x). On my FC29 system, this results in the following error:

[ 26%] Building NVCC (Device) object lib/PBA/CMakeFiles/pba.dir/pba_generated_ProgramCU.cu.o
In file included from /usr/include/cuda/cuda_runtime.h:83,
                 from <command-line>:
/usr/include/cuda/crt/host_config.h:129:2: error: #error -- unsupported GNU version! gcc versions later than 7 are not supported!
 #error -- unsupported GNU version! gcc versions later than 7 are not supported!

I experimented with changing the relevant statement in /usr/include/cuda/crt/host_config.h …

#if __GNUC__ > 7

#error -- unsupported GNU version! gcc versions later than 7 are not supported!

#endif /* __GNUC__ > 7 */

…but that triggers other errors (which may be in the build code that calls NVCC, but I haven’t analyzed that deep enough to be sure).

So, I find myself between a rock and a hard place. I had to abandon Ubuntu at 17.10 (and 18.04) because of a number of limitations (network interface, Wayland, but most importantly, not being able to use the 4.x kernels for latest docker/kubernetes versions). I ditched AMD GPUs because of poor driver support on CentOS 7.x (nVidia support is much better) and because of 3.x kernel versions. Now, I find CUDA is incompatible with current compilers in FC28 (branched from FC27 to Rawhide, which became official FC28 release on 2018-05-01) and FC29.

I get the impression that there may be quite a bit of a discrepancy between “driver support” for graphics output (well supported for 4.x kernel and GCC 8+) and “Cuda support” for taking advantage of GPU functionality (only 3.x kernel and GCC 7.x).

IMHO, Fedora is not very well suited for development due to the lack of installable compilers. E.g. Debian, Gentoo, their descendants and the like have side-by-side installable compilers so you can use any compiler you like without touching the system compiler. Though I don’t understand your issue with docker and the 4.x kernels on Ubuntu? Cuda isn’t depending on any kernel version, it just needs the driver working (which of course depends on kernel versions to some degree).

I agree that it would be better if Fedora would allow for multiple compiler versions (but I disagree about it not being good for development – its large user base provides good to great community support for solving problems).

I had to walk away (with a slightly broken heart) from Debian (switching from 6 to 7 was too painful) and Gentoo (too brittle and too much work for trying new software) and Suse (I perceived the community to be arrogant) several years ago, and from CentOS a bir more than a year ago (largely due to AMD drivers not being updated soon enough). As I alluded to before, the Ubuntu issue I dealt with was with switching from 16.04 or 17.04 to 17.10, when Canonical appeared to be starting its own silo. Maybe that problem has gone away since then.

Now, my comments above are not intended to knock any distros: They all have pros and cons – and it’s a matter of which or how much pain one can take. For the time being, it seems Fedora (with xfce and Cinnamon) offers the least painful compromise for me. Should I encounter an unsurmountable Fedora shipwreck (as I almost did with the FC27 to FC29 upgrade), I may give Debian another try (or ArchLinux, which seems to be more tolerant towards proprietary software) – however, neither Debian, nor ArchLinux, nor Gentoo are supported in the Cuda Toolkit.

As for “Cuda isn’t depending on any kernel version, it just needs the driver working”, I can only hope that this turns out to be true, but the GCC 7 dependency remains for now – and therefore Cuda code compilation breaks.

Then it’s probably less painful for you to just build gcc-7 on fedora from source and have it installed in /usr/local so you don’t break your system compiler.