Can multiple cuda kernels execute in parallel on the same SM?

Question

Suppose a cuda gpu with just one SM.

Can I start two cuda kernels in parallel that use say 512 threads? Or are kernels assigned in blocks, causing the kernels to be executed in series rather than in parallel, thus idling the remaining 512 cores for both executions?

I tried finding documentation describing the scheduling mechanisms behind nvidia gpus, but I could only find documentation that described how a single kernel gets resources allocated to it. It did not state if two kernels could be assigned to a single block in parallel, or if resources are allocated at a warp level, or maybe even a thread level.

I expect either block level or warp level resource sharing, but I'd like to understand the actual scheduling algorithms rather than guess, or reverse engineer.

Answer 1

I've lightly edited the question so that it is more-or-less sensible, and does not conflate software hierarchy (blocks) with hardware hierarchy (SMs, cuda cores, etc.) The comment stream clarifies OPs acknowledgement, in my view.

Yes, even on a single SM, it is possible for the block scheduler to deposit blocks from two different kernels.

Here is an example/test case:

$ /usr/local/cuda/samples/bin/x86_64/linux/release/deviceQuery
/usr/local/cuda/samples/bin/x86_64/linux/release/deviceQuery Starting...

 CUDA Device Query (Runtime API) version (CUDART static linking)

Detected 1 CUDA Capable device(s)

Device 0: "Quadro K610M"
  CUDA Driver Version / Runtime Version          11.4 / 11.4
  CUDA Capability Major/Minor version number:    3.5
  Total amount of global memory:                 981 MBytes (1028784128 bytes)
  (001) Multiprocessors, (192) CUDA Cores/MP:    192 CUDA Cores
  GPU Max Clock rate:                            954 MHz (0.95 GHz)
  Memory Clock rate:                             1300 Mhz
  Memory Bus Width:                              64-bit
  L2 Cache Size:                                 524288 bytes
  Maximum Texture Dimension Size (x,y,z)         1D=(65536), 2D=(65536, 65536), 3D=(4096, 4096, 4096)
  Maximum Layered 1D Texture Size, (num) layers  1D=(16384), 2048 layers
  Maximum Layered 2D Texture Size, (num) layers  2D=(16384, 16384), 2048 layers
  Total amount of constant memory:               65536 bytes
  Total amount of shared memory per block:       49152 bytes
  Total shared memory per multiprocessor:        49152 bytes
  Total number of registers available per block: 65536
  Warp size:                                     32
  Maximum number of threads per multiprocessor:  2048
  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)
  Maximum memory pitch:                          2147483647 bytes
  Texture alignment:                             512 bytes
  Concurrent copy and kernel execution:          Yes with 1 copy engine(s)
  Run time limit on kernels:                     Yes
  Integrated GPU sharing Host Memory:            No
  Support host page-locked memory mapping:       Yes
  Alignment requirement for Surfaces:            Yes
  Device has ECC support:                        Disabled
  Device supports Unified Addressing (UVA):      Yes
  Device supports Managed Memory:                Yes
  Device supports Compute Preemption:            No
  Supports Cooperative Kernel Launch:            No
  Supports MultiDevice Co-op Kernel Launch:      No
  Device PCI Domain ID / Bus ID / location ID:   0 / 1 / 0
  Compute Mode:
     < Default (multiple host threads can use ::cudaSetDevice() with device simultaneously) >

deviceQuery, CUDA Driver = CUDART, CUDA Driver Version = 11.4, CUDA Runtime Version = 11.4, NumDevs = 1
Result = PASS
$ cat t37.cu
#include <iostream>
__device__ volatile int s = 0;
__global__ void k1(){
  while (s == 0) {};
}
__global__ void k2(){
  s = 1;
}

int main(){

  cudaStream_t s1, s2;
  cudaStreamCreate(&s1);
  cudaStreamCreate(&s2);
  k1<<<1,1,0,s1>>>();
  k2<<<1,1,0,s2>>>();
  cudaDeviceSynchronize();
  cudaError_t err = cudaGetLastError();
  if (err != cudaSuccess) std::cout << cudaGetErrorString(err) << std::endl;
}
$ nvcc -o t37 t37.cu -arch=sm_35
nvcc warning : The 'compute_35', 'compute_37', 'compute_50', 'sm_35', 'sm_37' and 'sm_50' architectures are deprecated, and may be removed in a future release (Use -Wno-deprecated-gpu-targets to suppress warning).
$ ./t37
$

This is on a laptop with a Quadro K610M. deviceQuery shows us that this GPU has a single SM.

The test code shows two kernels. The first launched kernel (k1) will spin forever until the global location (s) becomes non-zero. The second launched kernel (k2) sets the global location to non-zero, allowing the first kernel to exit. The net result is normal application termination. If the two kernels were not scheduled at the same time, on the same SM (there is only 1) then the first kernel would spin forever, the second would never run, and the observed application behavior would be a hang. (You can witness a hang for example by launching both kernels into the same stream, eg. the default NULL stream.)

The fact that we do not see a hang means that both kernels ran at the same time, on the same SM.

There are a number of other questions here on the cuda SO tag which discuss block scheduling, and GPU scheduling behavior. Here is one example. There are others.

EDIT: Responding to a question in the comments, here is a test case that tries to find how many kernels can run "at once" on this single SM GPU:

$ cat t37.cu
#include <iostream>
#ifndef NL
#define NL 8
#endif
const int num_launches = NL;
__device__ volatile int s = 0;
__global__ void k(){
  atomicAdd((int *)(&s), 1);
  while (s < num_launches) {};
}

int main(){
  std::cout << "Number of kernels: " << num_launches << std::endl;
  cudaStream_t s[num_launches];
  for (int i = 0; i < num_launches; i++) cudaStreamCreate(s+i);
  for (int i = 0; i < num_launches; i++) k<<<1,1,0,s[i]>>>();
  cudaDeviceSynchronize();
  cudaError_t err = cudaGetLastError();
  if (err != cudaSuccess) std::cout << cudaGetErrorString(err) << std::endl;
}
$ nvcc -o t37 t37.cu -arch=sm_35 -DNL=16
nvcc warning : The 'compute_35', 'compute_37', 'compute_50', 'sm_35', 'sm_37' and 'sm_50' architectures are deprecated, and may be removed in a future release (Use -Wno-deprecated-gpu-targets to suppress warning).
$ ./t37
Number of kernels: 16
$

The above test case is successful for 16 kernels. If I compile instead with -DNL=32 the test case hangs. Referring to table 15 in the CUDA 11.4 programming guide, there are several relevant numbers for this cc3.5 GPU:

Maximum number of resident grids per device: 32

Maximum number of resident blocks per SM: 16

So we seem to have confirmed that if we go beyond 16 kernels, then we have exceeded the 16 blocks per SM limit, and the code will hang.