c++ - 在 ROS 上下文中使用基于 CUDA 的函数的正确方法

Question

我正在开发一个基于 ROS 的管道，其主要功能是订阅图像主题并持续执行特征检测、匹配等功能。为了使这个管道更快，我正在尝试使用基于 CUDA 的检测和匹配模块作为我的包的一部分。在这个问题的上下文中，我假设一个简单的管道，我在其中订阅了一个图像主题，并且在每次图像可用时调用的订阅者回调中，调用了不同类的两个成员函数:一个用于检测，另一个匹配，每个都包含自己的 CUDA 内核。有点类似于在循环中执行这两个函数。

第一个函数获取图像数据并计算特征关键点和描述符，并将它们返回给主机。然后我将这些描述符复制回 GPU 内存，我需要将它们与另一组属于引用图像的描述符相匹配。

例如，这是独立匹配函数的样子:

// Detection module returns a struct featureData, containing keypoints and descriptors 
// in featureData.kps and featureData.desc

uint64_t* d_desc;
cudaMalloc(&d_desc, 64 * featureData.kps.size());
cudaMemcpy(d_desc, &featureData., 64 * (featureData.kps.size()), cudaMemcpyHostToDevice);

cudaDeviceSetCacheConfig(cudaFuncCachePreferL1);
cudaDeviceSetSharedMemConfig(cudaSharedMemBankSizeEightByte);

// Create texture object for descriptors

struct cudaResourceDesc resDesc;
memset(&resDesc, 0, sizeof(resDesc));
resDesc.resType = cudaResourceTypeLinear;
resDesc.res.linear.devPtr = d_desc;
resDesc.res.linear.desc.f = cudaChannelFormatKindUnsigned;
resDesc.res.linear.desc.x = 32;
resDesc.res.linear.desc.y = 32;
resDesc.res.linear.sizeInBytes = 64 * featureData.kps.size();

struct cudaTextureDesc texDesc;
memset(&texDesc, 0, sizeof(texDesc));
texDesc.addressMode[0] = cudaAddressModeBorder;
texDesc.addressMode[1] = cudaAddressModeBorder;
texDesc.filterMode = cudaFilterModePoint;
texDesc.readMode = cudaReadModeElementType;
texDesc.normalizedCoords = 0;
cudaTextureObject_t tex_q = 0;
cudaCreateTextureObject(&tex_q, &resDesc, &texDesc, nullptr);

// Allocate space for match results
int* d_matches;
cudaMalloc(&d_matches, 4 * featureData.kps.size());

// Launch the matching kernel
CUDAmatch(d_descRef, static_cast<int>(refData.kps.size()), tex_q, static_cast<int>(featureData.kps.size()), d_matches, threshold);

// d_descRef is memory pointed to by a uint64_t* for the reference descriptors.

在这种情况下，我有几个问题，因为这是我第一次涉足基于 GPU 的开发。

1. 描述符等在执行匹配时被复制到设备内存中，然后将结果复制回来。我是否应该在每次执行匹配后释放这些设备内存指针并在下一个回调中重新分配 (cudaMalloc())？描述符的长度将根据检测到的特征数量而变化。或者是否有更有效的方法来仅分配一次内存并重用它？
2. 检测和匹配功能还使用了cudaResourceDesc 和cudaTextureDesc 等对象，它们在每次执行结束时都会超出范围，因此应该销毁.我应该以任何其他特定方式处理它们吗？
3. 我假设在执行这两个函数后我需要 cudaDeviceSynchronize()。我说得对吗？
4. 我能否安全地将“引用”描述符留在 GPU 内存中并仅在需要时更新它们？

Answer 1

Should I free the device memory pointers for these after performing matching every time and reallocate (cudaMalloc()) in the next callback?

可能不会。这似乎是不必要且耗时的。

Or is there a more efficient way to allocate memory only once and reuse it?

可能吧。例如，您可以确定可能需要的最大大小，为此进行分配，然后将指向它的指针传递到您的事件处理循环中，然后重新使用分配。

The detection and matching functions also make use of objects such as cudaResourceDesc and cudaTextureDesc, which will go out of scope at the end of every execution and thus should be destroyed. Should I handle them in any other specific way?

同样，您可以在更高的范围内创建它们，并将对它们的引用传递到您的事件处理系统中。但是，我认为这里的主要时间消费者将是填充纹理的数据拷贝，以及纹理的绑定(bind)。无论如何(大概)这些都必须重复。但是，如果您有纹理对象的后备存储的基础分配，那么您可能不需要为此重新分配，请参阅之前的评论。

I assume I need cudaDeviceSynchronize() after executing each of these two functions. Am I correct?

对我来说，它的必要性并不明显。你没有展示一个完整的例子，但是如果在你的函数结束时，有一个从设备到主机的数据拷贝，那可能就足够了。 cudaMemcpy 是一个阻塞函数。如果您在 TX1/TX2 等物理/逻辑统一内存情况下操作，那么是的，您可能需要一个同步点来确保数据在主机代码中使用之前有效。

Can I safely leave the "reference" descriptors in GPU memory and only update them when I need to?

我不知道为什么。由 cudaMalloc 创建的分配不会“超出范围”，直到应用程序终止或使用 cudaFree 显式释放。如果您将数据复制到这样的分配，它应该在您的应用程序期间保持不变，除非您以某种方式覆盖它(或释放底层分配)。