为什么CUDA会舍入线程使用的寄存器数量？

Question

I'm profiling a kernel that uses 25 registers per thread and 3568 bytes of shared memory per block in a GTX480. The kernel is configured to launch 16x16 threads and the thread cache preference is set to shared.

According to the specifications of the GTX480, the device has 32768 registers per SM, so It would be possible have 25 regs x 256 threads per block x 6 blocks per SM blocks running concurrently.

However, the Compute Visual Profiler and the Cuda Occupancy Calculator report that only 4 blocks will be active per SM. I was wondering why only 4 blocks would be active and not 5, as I expected.

The reason I found is that CUDA round up the number of registers used to 26, in which case, the number of active block is 4.

Why CUDA round up the number of registers? Because with 25 registers per thread and 256 threads per block it would be possible have up to 5 blocks per SM, which is obviously an advantage.

Environment setup:

Device 0: "GeForce GTX 480"
CUDA Driver Version / Runtime Version          5.0 / 4.0
ptxas info: Compiling entry function '_Z13kernellS_PiS0_iiS0_' for 'sm_20'
ptxas info: Used 25 registers, 3568+0 bytes smem, 80 bytes cmem[0], 16 bytes cmem[2]
0 bytes stack frame, 0 bytes spill stores, 0 bytes spill loads
kernel config: 16x16 threads per block
kernel config: cudaFuncCachePreferShared

Answer 1

You haven't interpreted what is happening correctly. There is no rounding of the number of registers per thread happening here, there is rounding of the number of registers per warp .

Your GPU allocated registers on a per warp basis, with a register "page size" of 64 registers (note I use that term loosely, I am not privy to the precise register file design). In your case a warp requires 25*32 = 800 registers, which must be rounded up to the nearest "page size" of 64, giving 832 registers per warp. Each block contains 8 warps (256 threads), so each block requires 6656 registers. The maximum number of blocks per SM for this kernel is then 32768 / 6656 rounded down to the nearest integer, ie. 4 blocks per SM rather than the 5 you expect.

So the very short answer is register file allocation granularity and page size is dictating how many blocks can be run per SM in this case.