Question

我正在使用带有nVidia 980 GTX的CUDA 7.0进行图像处理。在特定的迭代中，通过15-20个内核调用和多个cuFFT FFT / IFFT API调用独立处理多个tile。

因此，我将每个磁贴放在它自己的CUDA流中，这样每个磁贴就相对于主机异步执行它的操作串。每个图块在迭代中的大小相同，因此它们共享cuFFT计划。主机线程快速移动命令以试图保持GPU加载工作。我正在经历一个周期性的竞争条件，而这些操作正在并行处理，特别是有关于cuFFT的问题。如果我使用cuFFTSetStream（）为方块0在流0中放置一个cuFFT计划，并且在主机将共享cuFFT计划的流设置为第1个方案之前，尚未在GPU上实际执行方块0的FFT它会在GPU上发布tile 1的工作，cuFFTExec（）对此计划的行为是什么？

更简洁的是，cufftExec（）的调用是在cufftExec（）调用时计划设置的流中执行的，无论是否使用cuFFTSetStream（）在前一个FFT调用之前更改后续切片的流实际上已经开始/完成了吗？

我为不发布代码而道歉，但我无法发布我的实际来源。

Answer 1

编辑：正如评论中所指出的，如果相同的计划（相同的创建句柄）用于通过流在同一设备上同时执行FFT，则the user is responsible for managing separate work areas for each usage of such plan。问题似乎集中在流行为本身，我的回答也集中于此，但这是一个重点。

如果我使用cuFFTSetStream（）为方块0在流0中放置cuFFT计划，并且在主机设置共享cuFFT计划之前，实际上还没有在GPU上执行方块0的FFT。如果在GPU上发出磁贴1的工作之前，将流1发送到磁贴1，cuFFTExec（）对此计划的行为是什么？

让我假装你说流1和流2，这样我们就可以避免在NULL流周围出现任何可能的混淆。

CUFFT应尊重计划通过cufftExecXXX()传递给CUFFT时为计划定义的流。通过cufftSetStream()对计划进行的后续更改不应对用于以前发布的cufftExecXXX()电话的流产生任何影响。

我们可以使用分析器通过相当简单的测试来验证这一点。请考虑以下测试代码：

$ cat t1089.cu
// NOTE: this code omits independent work-area handling for each plan
// which is necessary for a plan that will be shared between streams
// and executed concurrently
#include <cufft.h>
#include <assert.h>
#include <nvToolsExt.h>

#define DSIZE 1048576
#define BATCH 100

int main(){

  const int nx = DSIZE;
  const int nb = BATCH;
  size_t ws = 0;
  cufftHandle plan;
  cufftResult res = cufftCreate(&plan);
  assert(res == CUFFT_SUCCESS);
  res = cufftMakePlan1d(plan, nx, CUFFT_C2C, nb, &ws);
  assert(res == CUFFT_SUCCESS);
  cufftComplex *d;
  cudaMalloc(&d, nx*nb*sizeof(cufftComplex));
  cudaMemset(d, 0, nx*nb*sizeof(cufftComplex));
  cudaStream_t s1, s2;
  cudaStreamCreate(&s1);
  cudaStreamCreate(&s2);
  res = cufftSetStream(plan, s1);
  assert(res == CUFFT_SUCCESS);
  res = cufftExecC2C(plan, d, d, CUFFT_FORWARD);
  assert(res == CUFFT_SUCCESS);
  res = cufftSetStream(plan, s2);
  assert(res == CUFFT_SUCCESS);
  nvtxMarkA("plan stream change");
  res = cufftExecC2C(plan, d, d, CUFFT_FORWARD);
  assert(res == CUFFT_SUCCESS);
  cudaDeviceSynchronize();
  return 0;
}


$ nvcc -o t1089 t1089.cu -lcufft -lnvToolsExt
$ cuda-memcheck ./t1089
========= CUDA-MEMCHECK
========= ERROR SUMMARY: 0 errors
$

我们只是连续两次正向FFT，在两者之间切换流。我们将使用nvtx marker来清楚地识别计划流关联更改请求发生的点。现在让我们看看nvprof --print-api-trace输出（删除冗长的启动前导码）：

983.84ms  617.00us  cudaMalloc
984.46ms  21.628us  cudaMemset
984.48ms  37.546us  cudaStreamCreate
984.52ms  121.34us  cudaStreamCreate
984.65ms     995ns  cudaPeekAtLastError
984.67ms     996ns  cudaConfigureCall
984.67ms     517ns  cudaSetupArgument
984.67ms  21.908us  cudaLaunch (void spRadix0064B::kernel1Mem<unsigned int, float, fftDirection_t=-1, unsigned int=32, unsigned int=4, CONSTANT, ALL, WRITEBACK>(kernel_parameters_t<fft_mem_radix1_t, unsigned int, float>) [416])
984.69ms     349ns  cudaGetLastError
984.69ms     203ns  cudaPeekAtLastError
984.70ms     296ns  cudaConfigureCall
984.70ms     216ns  cudaSetupArgument
984.70ms  8.8920us  cudaLaunch (void spRadix0064B::kernel1Mem<unsigned int, float, fftDirection_t=-1, unsigned int=32, unsigned int=4, CONSTANT, ALL, WRITEBACK>(kernel_parameters_t<fft_mem_radix1_t, unsigned int, float>) [421])
984.71ms     272ns  cudaGetLastError
984.71ms     177ns  cudaPeekAtLastError
984.72ms     314ns  cudaConfigureCall
984.72ms     229ns  cudaSetupArgument
984.72ms  9.9230us  cudaLaunch (void spRadix0256B::kernel3Mem<unsigned int, float, fftDirection_t=-1, unsigned int=16, unsigned int=2, L1, ALL, WRITEBACK>(kernel_parameters_t<fft_mem_radix3_t, unsigned int, float>) [426])
984.73ms     295ns  cudaGetLastError
984.77ms         -  [Marker] plan stream change
984.77ms     434ns  cudaPeekAtLastError
984.78ms     357ns  cudaConfigureCall
984.78ms     228ns  cudaSetupArgument
984.78ms  10.642us  cudaLaunch (void spRadix0064B::kernel1Mem<unsigned int, float, fftDirection_t=-1, unsigned int=32, unsigned int=4, CONSTANT, ALL, WRITEBACK>(kernel_parameters_t<fft_mem_radix1_t, unsigned int, float>) [431])
984.79ms     287ns  cudaGetLastError
984.79ms     193ns  cudaPeekAtLastError
984.80ms     293ns  cudaConfigureCall
984.80ms     208ns  cudaSetupArgument
984.80ms  7.7620us  cudaLaunch (void spRadix0064B::kernel1Mem<unsigned int, float, fftDirection_t=-1, unsigned int=32, unsigned int=4, CONSTANT, ALL, WRITEBACK>(kernel_parameters_t<fft_mem_radix1_t, unsigned int, float>) [436])
984.81ms     297ns  cudaGetLastError
984.81ms     178ns  cudaPeekAtLastError
984.81ms     269ns  cudaConfigureCall
984.81ms     214ns  cudaSetupArgument
984.81ms  7.4130us  cudaLaunch (void spRadix0256B::kernel3Mem<unsigned int, float, fftDirection_t=-1, unsigned int=16, unsigned int=2, L1, ALL, WRITEBACK>(kernel_parameters_t<fft_mem_radix3_t, unsigned int, float>) [441])
984.82ms     312ns  cudaGetLastError
984.82ms  152.63ms  cudaDeviceSynchronize
$

我们看到每个FFT操作都需要3个内核调用。在两者之间，我们看到我们的nvtx标记指示何时进行了计划流更改请求，并且在前3个内核启动之后但在最后3个内核之前发生这一点并不奇怪。最后，我们注意到基本上所有的执行时间都在最后的cudaDeviceSynchronize()调用中被吸收。所有前面的调用都是异步的，因此执行或多或少＆＃34;立即＆＃34;在第一毫秒的执行中。最终的同步吸收了6个内核的所有处理时间，总计大约150毫秒。

因此，如果cufftSetStream对cufftExecC2C()调用的第一次迭代产生影响，我们希望看到前三个内核中的部分或全部启动到与使用的相同的流中对于最后3个内核。但是当我们查看nvprof --print-gpu-trace输出时：

$ nvprof --print-gpu-trace ./t1089
==3757== NVPROF is profiling process 3757, command: ./t1089
==3757== Profiling application: ./t1089
==3757== Profiling result:
   Start  Duration            Grid Size      Block Size     Regs*    SSMem*    DSMem*      Size  Throughput           Device   Context    Stream  Name
974.74ms  7.3440ms                    -               -         -         -         -  800.00MB  106.38GB/s  Quadro 5000 (0)         1         7  [CUDA memset]
982.09ms  23.424ms          (25600 2 1)        (32 8 1)        32  8.0000KB        0B         -           -  Quadro 5000 (0)         1        13  void spRadix0064B::kernel1Mem<unsigned int, float, fftDirection_t=-1, unsigned int=32, unsigned int=4, CONSTANT, ALL, WRITEBACK>(kernel_parameters_t<fft_mem_radix1_t, unsigned int, float>) [416]
1.00551s  21.172ms          (25600 2 1)        (32 8 1)        32  8.0000KB        0B         -           -  Quadro 5000 (0)         1        13  void spRadix0064B::kernel1Mem<unsigned int, float, fftDirection_t=-1, unsigned int=32, unsigned int=4, CONSTANT, ALL, WRITEBACK>(kernel_parameters_t<fft_mem_radix1_t, unsigned int, float>) [421]
1.02669s  27.551ms          (25600 1 1)       (16 16 1)        61  17.000KB        0B         -           -  Quadro 5000 (0)         1        13  void spRadix0256B::kernel3Mem<unsigned int, float, fftDirection_t=-1, unsigned int=16, unsigned int=2, L1, ALL, WRITEBACK>(kernel_parameters_t<fft_mem_radix3_t, unsigned int, float>) [426]
1.05422s  23.592ms          (25600 2 1)        (32 8 1)        32  8.0000KB        0B         -           -  Quadro 5000 (0)         1        14  void spRadix0064B::kernel1Mem<unsigned int, float, fftDirection_t=-1, unsigned int=32, unsigned int=4, CONSTANT, ALL, WRITEBACK>(kernel_parameters_t<fft_mem_radix1_t, unsigned int, float>) [431]
1.07781s  21.157ms          (25600 2 1)        (32 8 1)        32  8.0000KB        0B         -           -  Quadro 5000 (0)         1        14  void spRadix0064B::kernel1Mem<unsigned int, float, fftDirection_t=-1, unsigned int=32, unsigned int=4, CONSTANT, ALL, WRITEBACK>(kernel_parameters_t<fft_mem_radix1_t, unsigned int, float>) [436]
1.09897s  27.913ms          (25600 1 1)       (16 16 1)        61  17.000KB        0B         -           -  Quadro 5000 (0)         1        14  void spRadix0256B::kernel3Mem<unsigned int, float, fftDirection_t=-1, unsigned int=16, unsigned int=2, L1, ALL, WRITEBACK>(kernel_parameters_t<fft_mem_radix3_t, unsigned int, float>) [441]

Regs: Number of registers used per CUDA thread. This number includes registers used internally by the CUDA driver and/or tools and can be more than what the compiler shows.
SSMem: Static shared memory allocated per CUDA block.
DSMem: Dynamic shared memory allocated per CUDA block.
$

我们看到实际上前3个内核被发布到第一个流中，最后3个内核被发布到第二个流中，就像请求一样。（并且所有内核的总执行时间大约为150ms，正如api跟踪输出所建议的那样。）由于底层内核启动是异步的，并且在cufftExecC2C()调用返回之前发出，如果您认为关于这一点，你会得出结论，它必须是这样的。启动内核的流在内核启动时指定。（当然，我认为这被视为＆＃34;首选＆＃34;行为。）

并发流中的CUDA cuFFT API行为

1 个答案: