CUDA小白 - NPP(10) 图像处理 Memory Management

MQTXWD

已于 2023-09-18 08:54:16 修改

阅读量261

点赞数

文章标签： c++ CUDA NPP

于 2023-09-14 16:32:24 首次发布

本文链接：https://blog.csdn.net/u011732139/article/details/132882409

版权

cuda小白
原始API链接 NPP

GPU架构近些年也有不少的变化，具体的可以参考别的博主的介绍，都比较详细。还有一些cuda中的专有名词的含义，可以参考《详解CUDA的Context、Stream、Warp、SM、SP、Kernel、Block、Grid》

常见的NppStatus，可以看这里。
本文主要涉及的是一些内存相关的操作，主要分为free和malloc的操作。free的接口比较基础一笔带过，malloc的有一定的说法。

void nppiFree(void * pData);

// 申请了三通道的uint8_t类型的，指定宽高的内存buffer
Npp8u* nppiMalloc_8u_C3(int nWidthPixels,
					    int nHeightPixels,
					    int *pStepBytes);

需要注意的是，如果使用默认的nppiMalloc_[TYPE]_C[CHANNEL]的结果，申请的空间会大于等于直接计算得到的空间值。因为会涉及到内部的字节对齐操作，因此实际的width * channel的如果不能被对齐字节数整除，就会默认padding部分直接，直到对齐。之所以这么操作有两个方面：

图像的宽度唯一，并且规整。（个人理解）
对齐后的操作会节省时间。

由于存在padding，因此如果初始的图像空间是使用nppiMalloc申请的，而非直接使用cudaMalloc的话，在使用过程中需要额外注意step的值，不然出来的结果会不正确。

PS：
其实在写前面的例子的时候，我就已经直到了对齐后的会带来性能的提升，之所以不用，有一个最直接的原因是：第一次接触NPP的时候，主要是用于模型的一些前处理操作。因为存在padding，因此在送给模型的时候的时候需要额外进行一次拷贝（以前就是一行一行的cudaMemcpy操作的，但是懵懂无知，应该可以直接使用nppiCopy进行拷贝，哈哈哈哈），感觉有这个时间，padding带来的性能提升没啥太大的区别。（没有实际测试过，有大佬觉的有问题，欢迎指出）