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.
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.