To my understanding it's more accurate to say: func1 is executed at least for the first 512 threads.īefore I edited this answer (back in 2010) I measured 14x8x32 threads were synchronized using _syncthreads. I'm not sure about the exact number of threads that _syncthreads can synchronize, since you can create a block with more than 512 threads and let the warp handle the scheduling. The main point is _syncthreads is a block-wide operation and it does not synchronize all threads. func2 is executed for the remaining threads.func1 is executed for the remaining threads.func2 is executed for the first 512 threads.func1 is executed for the first 512 threads.Then the kernel must run twice and the order of execution will be: If you execute the following with 600 threads: func1()
warpsize is 32 (which means each of the 14x8=112 thread-processors can schedule up to 32 threads)Ī block cannot have more active threads than 512 therefore _syncthreads can only synchronize limited number of threads.each SM has 8 thread-processors (AKA stream-processors, SP or cores).Uint j = (blockIdx.y * blockDim.y) + threadIdx.y In the kernel the pixel (i,j) to be processed by a thread is calculated this way: uint i = (blockIdx.x * blockDim.x) + threadIdx.x The threads of a block can be indentified (indexed) using 1Dimension(x), 2Dimensions (x,y) or 3Dim indexes (x,y,z) but in any case x yz >( /* params for the kernel function */ ) įinally: there will be something like "a queue of 4096 blocks", where a block is waiting to be assigned one of the multiprocessors of the GPU to get its 64 threads executed. A block is executed by a multiprocessing unit. If a GPU device has, for example, 4 multiprocessing units, and they can run 768 threads each: then at a given moment no more than 4*768 threads will be really running in parallel (if you planned more threads, they will be waiting their turn).
0 kommentar(er)
