cudaErrorNotSupported during cudaMallocAsync on Windows 10 based Azure VM with Tesla T4 GPU

Hello,

I have a weird error in my application on Windows 10-based Azure VM with Tesla T4 GPU. I’m getting cudaErrorNotSupported (801) returned by any cudaMallocAsync() method. Code builds without any problems on this VM, GPU device identified correctly, but I’m always getting this cudaErrorNotSupported error.

The same code without any changes works on all physical Windows 10 machines in my team, on Ubuntu 22.04 Azure VM with the same Tesla T4 GPU, inside WSL2 and Docker containers.

What is interesting, is that all samples from the CUDA samples repository work correctly.

But the only differences I was able to identify between my code and the CUDA samples, are:

  • CUDA samples use min Compute Capability of 5.2, but my app uses 7.5 (tried to change it in my app - didn’t help).
  • CUDA samples use C++11, my code C++20.

Results of Device query from this Azure VM:

CUDA Device Query (Driver API) statically linked version
Detected 1 CUDA Capable device(s)

Device 0: "Tesla T4"
  CUDA Driver Version:                           12.1
  CUDA Capability Major/Minor version number:    7.5
  Total amount of global memory:                 16218 MBytes (17005740032 bytes)
  (40) Multiprocessors, ( 64) CUDA Cores/MP:     2560 CUDA Cores
  GPU Max Clock rate:                            1590 MHz (1.59 GHz)
  Memory Clock rate:                             5001 Mhz
  Memory Bus Width:                              256-bit
  L2 Cache Size:                                 4194304 bytes
  Max Texture Dimension Sizes                    1D=(131072) 2D=(131072, 65536) 3D=(16384, 16384, 16384)
  Maximum Layered 1D Texture Size, (num) layers  1D=(32768), 2048 layers
  Maximum Layered 2D Texture Size, (num) layers  2D=(32768, 32768), 2048 layers
  Total amount of constant memory:               65536 bytes
  Total amount of shared memory per block:       49152 bytes
  Total number of registers available per block: 65536
  Warp size:                                     32
  Maximum number of threads per multiprocessor:  1024
  Maximum number of threads per block:           1024
  Max dimension size of a thread block (x,y,z): (1024, 1024, 64)
  Max dimension size of a grid size (x,y,z):    (2147483647, 65535, 65535)
  Texture alignment:                             512 bytes
  Maximum memory pitch:                          2147483647 bytes
  Concurrent copy and kernel execution:          Yes with 3 copy engine(s)
  Run time limit on kernels:                     No
  Integrated GPU sharing Host Memory:            No
  Support host page-locked memory mapping:       Yes
  Concurrent kernel execution:                   Yes
  Alignment requirement for Surfaces:            Yes
  Device has ECC support:                        Disabled
  CUDA Device Driver Mode (TCC or WDDM):         TCC (Tesla Compute Cluster Driver)
  Device supports Unified Addressing (UVA):      Yes
  Device supports Managed Memory:                Yes
  Device supports Compute Preemption:            Yes
  Supports Cooperative Kernel Launch:            Yes
  Supports MultiDevice Co-op Kernel Launch:      Yes
  Device PCI Domain ID / Bus ID / location ID:   1 / 0 / 0
  Compute Mode:
     < Default (multiple host threads can use ::cudaSetDevice() with device simultaneously) >
Result = PASS

I also found that on local machines “CUDA Device Driver Mode” is WWDM, but on the Azure VM - TCC. Not sure if it has any impact.

I completely do not understand what causes this issue. Would be grateful for any advice.

I think you should probably take your observations at face value:
Support for cudaMallocAsync:

  • native windows, WDDM: yes
  • native windows, TCC: no
  • windows WSL2: yes
    (or if you prefer, construct a directed test in each of the above 3 settings to determine support for cuda memory pools as indicated by the api mechanism)

I’m not suggesting these are hard and fast rules and may not change in the future. The instructions give the method to determine if it is supported in any particular setting. if it is not supported, then use whatever coding methodology you would have used prior to the introduction of CUDA memory pools.

I won’t be able to explain what causes the issue. Code that is designed to run in a variety of settings should acknowledge that cuda memory pools are not supported in every setting, and should properly query for support, and should behave accordingly if support is not indicated.

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.