Unable to get Decoding Capabilities by cuvidGetDecoderCaps CUDA SDK - cuda

I have a server with Tesla T4 GPU. I am trying to decode an H264 video on GPU. I am using Cuda SDK to get CUVIDDECODECAPS (decoding capabilities of GPU) but it is returning 0 to MinWidth, MinHeight, MaxWidth, MaxHeight, and false to "bIsSupported". ie. This hardware doesn't support decoding on GPU. But according to this link T4 does support video decoding.
Below is the code snippet.
CUVIDDECODECAPS decodeCaps = {};
decodeCaps.eCodecType = _codec;
decodeCaps.eChromaFormat = _chromaFormat;
decodeCaps.nBitDepthMinus8 = videoFormat.nBitDepthMinus8;
cuSafeCall(cuCtxPushCurrent(ctx_));
cuSafeCall(cuvidGetDecoderCaps(&decodeCaps));
cuSafeCall(cuCtxPopCurrent(NULL));
Below is driver and cuda version
NVIDIA-SMI 440.118.02 Driver Version: 440.118.02 CUDA Version: 10.2 Nvidia Video codec SDK is 11.0.10
Does anyone have any idea what's wrong I am doing here?

Each Nvidia Video SDK has minimal requirements for CUDA SDK and graphics driver version. If you open the SDK web page you will find this info:
NVIDIA Windows display driver 456.71 or newer
NVIDIA Linux display driver 455.28 or newer
DirectX SDK (Windows only) CUDA 11.0 Toolkit
At least on Linux, the related NVENC and NVDEC libraries are part of the driver distribution so the latest SDK headers cannot work with the old libs ( according to your driver version). You can download the older version of the Video SDK if you must use that specific driver.

Related

Autolykos GPU Miner software no longer recognizing NVIDIA GPU on Ubuntu 18.04

A month or so ago, Autolykos miner (https://github.com/ergoplatform/Autolykos-GPU-miner) compiled and ran. Now suddenly it doesn't work because the .cu files don't recognize any installed NVIDIA GPU. I made NO changes to the Autolykos code--it just stopped working. I merely dropped into the source folder (as described by the README) and typed make. But when I install and make all of the CUDA examples, THOSE run just fine. Running on UBUNTU 18.04 with a GeForce TITAN X. For example, the utility "deviceQuery" returns the following:
./deviceQuery Starting...
CUDA Device Query (Runtime API) version (CUDART static linking)
Detected 1 CUDA Capable device(s)
Device 0: "GeForce GTX TITAN X"
CUDA Driver Version / Runtime Version 10.1 / 10.1
CUDA Capability Major/Minor version number: 5.2
...
Whereas the output at startup of the mining binary spits out ONE line and quits:
Error Checking GPU: Using 0 GPU devices
Any suggestions would be welcome...
SOLVED: After re-compiling the CUDA code from NVIDIA, the miner is working. I suspect that a system update broke something

PyCUDA mem_get_ipc_handle gives LogicError: cuIpcGetMemHandle failed: operation not supported

I am trying to execute the code here. I get the following error:
orig: [0.36975162 0.08511397 0.16306844 0.4015488 0.25104857 0.30606773 0.24524205 0.13792656]
Process Process-1:
Traceback (most recent call last):
File "C:\Program Files\Python27\lib\multiprocessing\process.py", line 267, in _bootstrap
self.run()
File "C:\Program Files\Python27\lib\multiprocessing\process.py", line 114, in run
self._target(*self._args, **self._kwargs)
File "C:\Users\My\Desktop\test_codes\pycuda4.py", line 28, in func1
h = drv.mem_get_ipc_handle(x_gpu.ptr)
LogicError: cuIpcGetMemHandle failed: operation not supported
I am using Python 3.7, CUDA 9.2 in Windows 7 x64 environment. Is CUDA IPCMemoryHandle not supported in Windows? Or, am I missing something?
What is documented here is that CUDA IPC functionality is only supported on Linux.
However, the driver API (upon which PyCUDA is based) docs indicate:
IPC functionality is restricted to devices with support for unified addressing on Linux and Windows operating systems. IPC functionality on Windows is restricted to GPUs in TCC mode
Therefore if you can put your windows GPU in TCC mode (via nvidia-smi tool) then I think it should probably work/be supported. GeForce GPUs cannot be put in TCC mode. Most Titan and Quadro GPUs can be placed in TCC mode. Most Tesla GPUs on windows should automatically be in TCC mode. Note that putting your GPU in TCC mode means it cannot host a display any longer.
In recent CUDA toolkits, IPC support has been added for both WDDM and TCC usage in windows (the underlying mechanisms are different). The CUDA IPC sample code demonstrates all flavors (linux, windows TCC, windows WDDM).

CUDA Installation for NVidia Quadro FX 3800

I'm having trouble installing CUDA 7.0 (to use with TensorFlow) on a workstation with the Nvidia Quadro FX 3800. I'm wondering if this is because the GPU is no longer supported.
Installation of the driver (340.96) seems to work fine:
$ sh ./NVIDIA-Linux-x86_64-340.96.run
Installation of the NVIDIA Accelerated Graphics Driver for Linux-x86_64
(version: 340.96) is now complete. Please update your XF86Config or
xorg.conf file as appropriate; see the file
/usr/share/doc/NVIDIA_GLX-1.0/README.txt for details.
However, I think I may be having trouble with the following:
$ ./cuda_7.0.28_linux.run --kernel-source-path=/usr/src/linux-headers-3.13.0-76-generic
The driver installation is unable to locate the kernel source. Please make sure
that the kernel source packages are installed and set up correctly. If you know
that the kernel source packages are installed and set up correctly, you may pass
the location of the kernel source with the '--kernel-source-path' flag.
...
Logfile is /tmp/cuda_install_1357.log
$ vi /tmp/cuda_install_1357.log
WARNING: The NVIDIA Quadro FX 3800 GPU installed in this system is
supported through the NVIDIA 340.xx legacy Linux graphics drivers.
Please visit http://www.nvidia.com/object/unix.html for more
information. The 346.46 NVIDIA Linux graphics driver will ignore
this GPU.
WARNING: You do not appear to have an NVIDIA GPU supported by the 346.46
NVIDIA Linux graphics driver installed in this system. For
further details, please see the appendix SUPPORTED NVIDIA GRAPHICS
CHIPS in the README available on the Linux driver download page at
www.nvidia.com.
...
ERROR: Unable to load the kernel module 'nvidia.ko'. This happens most
frequently when this kernel module was built against the wrong or
improperly configured kernel sources, with a version of gcc that
differs from the one used to build the target kernel, or if a driver
such as rivafb, nvidiafb, or nouveau is present and prevents the
NVIDIA kernel module from obtaining ownership of the NVIDIA graphics
device(s), or no NVIDIA GPU installed in this system is supported by
this NVIDIA Linux graphics driver release.
...
Please see the log entries 'Kernel module load error' and 'Kernel
messages' at the end of the file '/var/log/nvidia-installer.log' for
more information.
Is the installation failure due to CUDA dropping support for this graphics card?
I followed the link trail: https://developer.nvidia.com/cuda-gpus > https://developer.nvidia.com/cuda-legacy-gpus > http://www.nvidia.com/object/product_quadro_fx_3800_us.html and I would have thought the Quadro FX 3800 supported CUDA (at least at the beginning).
Yes, the Quadro FX 3800 GPU is no longer supported by CUDA 7.0 and beyond.
The last CUDA version that supported that GPU was CUDA 6.5.
This answer and this answer may be of interest. Your QFX 3800 is a compute capability 1.3 device.
If you review the release notes that come with CUDA 7, you will find a notice of the elimination of support for these earlier GPUs. Likewise, the newer CUDA driver versions also don't support those GPUs.

CUDA driver API: Where is nvcuda?

The CUDA C Programming Guide Version 4.2 states:
The driver API is implemented in the nvcuda dynamic library which is copied on
the system during the installation of the device driver.
I installed the RC5.0 devdriver on my Linux box along with SDK 4.2 and 5.0. Right now I have difficulties finding this library. Its not in (or under) /usr, /lib, /lib64, nor in one of the SDK libs:
CUDA 4.2:
ls /usr/local/cuda-4.2/cuda/lib64/
libcublas.so libcudart.so libcufft.so libcuinj.so libcurand.so libcusparse.so libnpp.so
libcublas.so.4 libcudart.so.4 libcufft.so.4 libcuinj.so.4 libcurand.so.4 libcusparse.so.4 libnpp.so.4
libcublas.so.4.2.9 libcudart.so.4.2.9 libcufft.so.4.2.9 libcuinj.so.4.2.9 libcurand.so.4.2.9 libcusparse.so.4.2.9 libnpp.so.4.2.9
CUDA 5.0:
ls /usr/local/cuda-5.0/cuda/lib64/
libcublas.so libcudart.so libcufft.so libcuinj.so libcurand.so libcusparse.so libnpp.so libnvToolsExt.so
libcublas.so.5.0 libcudart.so.5.0 libcufft.so.5.0 libcuinj.so.5.0 libcurand.so.5.0 libcusparse.so.5.0 libnpp.so.5.0 libnvToolsExt.so.5.0
libcublas.so.5.0.7 libcudart.so.5.0.7 libcufft.so.5.0.7 libcuinj.so.5.0.7 libcurand.so.5.0.7 libcusparse.so.5.0.7 libnpp.so.5.0.7 libnvToolsExt.so.5.0.7
Where is this library installed to?
It's not that the driver API is not included in the RC 5.0. I just reinstalled devdriver 4.2 and its still not in the above mentioned places.
Found it. But under a different name (libcuda instead libnvcuda):
/usr/lib/libcuda.so.295.41
This must be a typo/error in the manual.
libcuda is always by default installed to /usr/lib/ and on 64bit linux /usr/lib64
See also Chapter 5. Listing of Installed Components for list and locations of other driver components.

CUDA Toolkit 4.1/4.2: nvcc Crashes with an Access Violation

I am developing a CUDA application for GTX 580 with Visual Studio 2010 Professional on Windows 7 64bit. My project builds fine with CUDA Toolkit 4.0, but nvcc crashes when I choose CUDA Toolkit 4.1 or 4.2 with the following error:
1> Stack dump:
1> 0. Running pass 'Promote Constant Global' on module 'moduleOutput'.
1>CUDACOMPILE : nvcc error : 'cicc' died with status 0xC0000005 (ACCESS_VIOLATION)
Strangely enough, the program compiles OK with "compute_10,sm_10" specified for "Code Generation", but "compute_20,sm_20" does not work. The code in question can be downloaded here:
http://www.meriken2ch.com/files/CUDA_SHA-1_Tripper_MERIKENs_Branch_0.04_Alpha_1.zip
(README.txt is in Japanese, but comments in source files are in English.)
I am suspecting a newly introduced bug in CUDA Toolkit 4.1/4.2. Has anybody encountered this issue? Is there any workaround for it? Any kind of help will be much appreciated.
This appears to have been a compiler bug in CUDA 4.x that is fixed in CUDA 5.0 (according to a comment from #meriken2ch, the project builds fine with CUDA 5.0 RC).