kernel

先抛出一个问题#xff0c;如果在一个循环中不断的发送kernel#xff08;kernel

内部while死循环#xff09;#xff0c;会是什么结果。

kernel

先抛出一个问题如果在一个循环中不断的发送kernelkernel

kernel

设置cudaLimitDevRuntimePendingLaunchCount为128/1000等cudaDeviceSetLimit(cudaLimitDevRuntimePendingLaunchCount,

128)//3.

block_dim一次性占满所有资源或者1,1kernelgrid_dim,

block_dim,

销毁资源sync();StreamDestroy(stream1);

其中还有一个简单的办法首先在stream中发射一个阻塞的hostfun然后发送空kernel也能计算到其大小参考部分有相关代码结果

持续的发送一个小kernel到1个stream中在1022次kernal

launch

后host出现block。

3个stream中现象和1个stream一样也是在1022次后被阻塞住。

详细参数如下(无论cudaLimitDevRuntimePendingLaunchCount设置为多少下面结果没有变化)

indexgriddimblockdimstremresult1111从1022次开始阻塞2113从1022次开始阻塞317281281从1022次开始阻塞417281283从1022次开始阻塞617281288从1022次开始阻塞71/17281/12812约~743次开始阻塞81/17281/12816约~550次开始阻塞91/17281/12848约~224次开始阻塞101/17281/128128约~12-33次开始阻塞

cudaLimitDevRuntimePendingLaunchCount

的设置对结果没有影响上面表格中cudaLimitDevRuntimePendingLaunchCount无论设置为1282561000等最后结果都是一样的。

因为它是CUDA

Dynamic

被map到另外一个叫做channel的对象上对于正在执行或者pending状态的item都会在queue中占用资源直到其完成。

上面都说明限制在某个stream上launch

kernel的瓶颈点是一个host端侧的资源所以排除cudaLimitDevRuntimePendingLaunchCount因为它是一个device侧的资源控制量。

queue最后都是被map到channel上channel的数量是有限的并且channel又分为很多类型,不同类型其capacity也不一样其中看实验结果其中CU_CHANNEL_COMPUTE类型的只有8个并且每个channel容纳1022个kernel

如果stream数量少于channel的数量那么每个stream对应一个channel如果stream的数量大于channeldistributes

work

cuiLaunchstreamBeginPushWithFlagsstreamBeginPushWithDescstreamBeginPushOnChannelWithFlagschannelBeginPushInternalchannelBeginPushInternal_UnderLockchannelMustAdvance_UnderlockchannelMustAdvance_WaitForGPFIFOchannelCanAdvanceGPFIFO在这里判断pushbuf和fifo

entrygpfifoHasPushbufferSpacegpfifoAdvanceGpuGetpushbufferHasSpace整个调用链是这样的

当向stream中下发kerneL的时候stream会找到一个channel该channel中有一个gpfifo的queue其内部有一个ring_buffer(4M)另外还维护着一个semaphore

queue(Max1024)我们下发的每个kernel都会写道对应的ring_buffer中并且每个kernel对专门对应一个semaphore

entry放在semaphore

queue中当GPU开始执行kernel的时候ring_buffer中的kernel

发送一个semaphore

entry让其释放资源因为fifo有顺序要求所以如果前面的kernel没有执行完后面的kernel执行完那么依然会block.也就是说只要第一个kernel在执行即使后面全部是empty

kernel