CUDA的nppiMalloc...函数如何保证内存对齐？

Question

有一段时间以来，我对所分配的CUDA内存的对齐要求感到困惑。我知道，如果它们对齐，访问行元素将更加高效。

首先，简单介绍一下背景：根据CUDA C编程指南（第5.3.2节）：

全局内存位于设备内存中，可以通过32、64或128字节的内存事务访问设备内存。这些内存事务必须自然对齐。只有对齐到其大小（即其第一个地址是其大小的倍数）的设备内存的32、64或128字节段才能由内存事务读取或写入。

我的理解是，对于类型为T的2D交错数组（例如按R,G,B顺序排列的像素值），如果numChannels*sizeof(T)等于4、8或16，则如果需要性能，必须使用cudaMallocPitch来分配该数组。到目前为止，这对我一直运行良好。在分配2D数组之前，我会检查numChannels*sizeof(T)，如果它是4、16或32，则使用cudaMallocPitch进行分配，并且一切正常。

现在的问题是：我意识到在使用NVIDIA的NPP库时，有一组分配器函数（nppiMalloc... 如nppiMalloc_32f_C1等）。 NVIDIA建议使用这些函数以提高性能。我的问题是，这些函数如何保证对齐？更具体地说，它们使用什么样的数学来得出适当的pitch值？

对于一个单通道512x512像素图像（带有范围在[0,1]之间的浮点像素值），我已经同时使用了cudaMallocPitch和nppiMalloc_32f_C1。cudaMallocPitch给了我2048的pitch值，而nppiMalloc_32f_C1给了我2560。后者的值从何而来，这是如何实现的呢？

为什么我关心这个问题：我正在编写一个同步内存类模板，用于在GPU和CPU上同步值。这个类应该负责在幕后分配间隔内存（如果可能）。由于我希望这个类与NVIDIA的NPP可互操作，因此我希望以一种提供CUDA内核和NPP操作良好性能的方式处理所有分配。我的印象是nppiMalloc在幕后调用cudaMallocPitch，但看来我错了。

- Maghoumi

---

@sgarizvi 感谢您的慷慨奖励，先生。 - Maghoumi

Answer 1

一个有趣的问题。然而，可能没有明确的答案，原因如下：这些方法的实现并不是公开的。人们必须假设NVIDIA在内部使用了一些特殊的技巧和调整。此外：结果的间距没有被指定。因此，人们必须假设它可能会在几个CUDA/NPP版本之间发生变化。特别是，实际间距很可能取决于执行该方法的设备的硬件版本（“计算能力”）。

尽管如此，我对此很感兴趣，写了以下测试：

#include <stdio.h>
#include <npp.h>

template <typename T>
void testStepBytes(const char* name, int elementSize, int numComponents, 
    T (*allocator)(int, int, int*))
{
    printf("%s\n", name);
    int dw = 1;
    int prevStepBytes = 0;
    for (int w=1; w<2050; w+=dw)
    {
        int stepBytes;
        void *p = allocator(w, 1, &stepBytes);
        nppiFree(p);
        if (stepBytes != prevStepBytes)
        {
            printf("Stride %5d is used up to w=%5d (%6d bytes)\n", 
                prevStepBytes, (w-dw), (w-dw)*elementSize*numComponents);
            prevStepBytes = stepBytes;
        }
    }
}

int main(int argc, char *argv[])
{
    testStepBytes("nppiMalloc_8u_C1", 1, 1, &nppiMalloc_8u_C1);
    testStepBytes("nppiMalloc_8u_C2", 1, 2, &nppiMalloc_8u_C2);
    testStepBytes("nppiMalloc_8u_C3", 1, 3, &nppiMalloc_8u_C3);
    testStepBytes("nppiMalloc_8u_C4", 1, 4, &nppiMalloc_8u_C4);

    testStepBytes("nppiMalloc_16u_C1", 2, 1, &nppiMalloc_16u_C1);
    testStepBytes("nppiMalloc_16u_C2", 2, 2, &nppiMalloc_16u_C2);
    testStepBytes("nppiMalloc_16u_C3", 2, 3, &nppiMalloc_16u_C3);
    testStepBytes("nppiMalloc_16u_C4", 2, 4, &nppiMalloc_16u_C4);

    testStepBytes("nppiMalloc_32f_C1", 4, 1, &nppiMalloc_32f_C1);
    testStepBytes("nppiMalloc_32f_C2", 4, 2, &nppiMalloc_32f_C2);
    testStepBytes("nppiMalloc_32f_C3", 4, 3, &nppiMalloc_32f_C3);
    testStepBytes("nppiMalloc_32f_C4", 4, 4, &nppiMalloc_32f_C4);

    return 0;
}

步长（stepBytes）似乎完全取决于图像的宽度。因此，该程序为不同类型的图像分配内存，并增加宽度，打印有关导致特定步幅的最大图像大小的信息。目的是推导出一种模式或规则——即您所询问的“某种数学”。

结果有些令人困惑。例如，在我的计算机上（CUDA 6.5，GeForce GTX 560 Ti，计算能力2.1），对于nppiMalloc_32f_C1调用，它打印：

nppiMalloc_32f_C1
Stride     0 is used up to w=    0 (     0 bytes)
Stride   512 is used up to w=  120 (   480 bytes)
Stride  1024 is used up to w=  248 (   992 bytes)
Stride  1536 is used up to w=  384 (  1536 bytes)
Stride  2048 is used up to w=  504 (  2016 bytes)
Stride  2560 is used up to w=  640 (  2560 bytes)
Stride  3072 is used up to w=  768 (  3072 bytes)
Stride  3584 is used up to w=  896 (  3584 bytes)
Stride  4096 is used up to w= 1016 (  4064 bytes)
Stride  4608 is used up to w= 1152 (  4608 bytes)
Stride  5120 is used up to w= 1280 (  5120 bytes)
Stride  5632 is used up to w= 1408 (  5632 bytes)
Stride  6144 is used up to w= 1536 (  6144 bytes)
Stride  6656 is used up to w= 1664 (  6656 bytes)
Stride  7168 is used up to w= 1792 (  7168 bytes)
Stride  7680 is used up to w= 1920 (  7680 bytes)
Stride  8192 is used up to w= 2040 (  8160 bytes)

确认对于宽度为512的图像，它将使用2560的跨度。预期的2048的跨度将用于宽度达到504的图像。

这些数字似乎有点奇怪，因此我进行了另一个测试nppiMalloc_8u_C1，以涵盖所有可能的图像行大小（以字节为单位），使用更大的图像尺寸，并注意到一个奇怪的模式：第一次增加间距大小（从512到1024）发生在图像大于480字节时，而480 = 512-32。下一步（从1024到1536）发生在图像大于992字节时，而992 = 480 + 512。下一步（从1536到2048）发生在图像大于1536字节时，而1536 = 992 + 512 + 32。从那里开始，它似乎主要按512的步长运行，除了其中几个尺寸。进一步的步骤概述如下：

nppiMalloc_8u_C1
Stride      0 is used up to w=     0 (     0 bytes, delta     0)
Stride    512 is used up to w=   480 (   480 bytes, delta   480)
Stride   1024 is used up to w=   992 (   992 bytes, delta   512)
Stride   1536 is used up to w=  1536 (  1536 bytes, delta   544)
Stride   2048 is used up to w=  2016 (  2016 bytes, delta   480) \
Stride   2560 is used up to w=  2560 (  2560 bytes, delta   544) | 4
Stride   3072 is used up to w=  3072 (  3072 bytes, delta   512) |
Stride   3584 is used up to w=  3584 (  3584 bytes, delta   512) /
Stride   4096 is used up to w=  4064 (  4064 bytes, delta   480)     \
Stride   4608 is used up to w=  4608 (  4608 bytes, delta   544)     |
Stride   5120 is used up to w=  5120 (  5120 bytes, delta   512)     |
Stride   5632 is used up to w=  5632 (  5632 bytes, delta   512)     | 8
Stride   6144 is used up to w=  6144 (  6144 bytes, delta   512)     |
Stride   6656 is used up to w=  6656 (  6656 bytes, delta   512)     |
Stride   7168 is used up to w=  7168 (  7168 bytes, delta   512)     |
Stride   7680 is used up to w=  7680 (  7680 bytes, delta   512)     /
Stride   8192 is used up to w=  8160 (  8160 bytes, delta   480) \
Stride   8704 is used up to w=  8704 (  8704 bytes, delta   544) |
Stride   9216 is used up to w=  9216 (  9216 bytes, delta   512) |
Stride   9728 is used up to w=  9728 (  9728 bytes, delta   512) |
Stride  10240 is used up to w= 10240 ( 10240 bytes, delta   512) |
Stride  10752 is used up to w= 10752 ( 10752 bytes, delta   512) |
Stride  11264 is used up to w= 11264 ( 11264 bytes, delta   512) |
Stride  11776 is used up to w= 11776 ( 11776 bytes, delta   512) | 16
Stride  12288 is used up to w= 12288 ( 12288 bytes, delta   512) |
Stride  12800 is used up to w= 12800 ( 12800 bytes, delta   512) |
Stride  13312 is used up to w= 13312 ( 13312 bytes, delta   512) |
Stride  13824 is used up to w= 13824 ( 13824 bytes, delta   512) |
Stride  14336 is used up to w= 14336 ( 14336 bytes, delta   512) |
Stride  14848 is used up to w= 14848 ( 14848 bytes, delta   512) |
Stride  15360 is used up to w= 15360 ( 15360 bytes, delta   512) |
Stride  15872 is used up to w= 15872 ( 15872 bytes, delta   512) /
Stride  16384 is used up to w= 16352 ( 16352 bytes, delta   480)     \
Stride  16896 is used up to w= 16896 ( 16896 bytes, delta   544)     |
Stride  17408 is used up to w= 17408 ( 17408 bytes, delta   512)     |
...                                                                ... 32
Stride  31232 is used up to w= 31232 ( 31232 bytes, delta   512)     |
Stride  31744 is used up to w= 31744 ( 31744 bytes, delta   512)     |
Stride  32256 is used up to w= 32256 ( 32256 bytes, delta   512)     /
Stride  32768 is used up to w= 32736 ( 32736 bytes, delta   480) \
Stride  33280 is used up to w= 33280 ( 33280 bytes, delta   544) |
Stride  33792 is used up to w= 33792 ( 33792 bytes, delta   512) |
Stride  34304 is used up to w= 34304 ( 34304 bytes, delta   512) |
...                                                            ... 64
Stride  64512 is used up to w= 64512 ( 64512 bytes, delta   512) |
Stride  65024 is used up to w= 65024 ( 65024 bytes, delta   512) /
Stride  65536 is used up to w= 65504 ( 65504 bytes, delta   480)     \
Stride  66048 is used up to w= 66048 ( 66048 bytes, delta   544)     |   
Stride  66560 is used up to w= 66560 ( 66560 bytes, delta   512)     |
Stride  67072 is used up to w= 67072 ( 67072 bytes, delta   512)     |
....                                                               ... 128
Stride 130048 is used up to w=130048 (130048 bytes, delta   512)     |
Stride 130560 is used up to w=130560 (130560 bytes, delta   512)     /
Stride 131072 is used up to w=131040 (131040 bytes, delta   480) \
Stride 131584 is used up to w=131584 (131584 bytes, delta   544) |
Stride 132096 is used up to w=132096 (132096 bytes, delta   512) |
...                                                              | guess...

很显然有一个模式。这些音高与512的倍数相关。对于大小为512*2ⁿ，其中n是整数，有一些奇怪的-32和+32偏移量，导致使用更大的音高。也许我会再看看这个问题。我很确定可以推导出公式来覆盖这个奇怪的音高进展。但是：这可能取决于底层CUDA版本、NPP版本，甚至所使用的卡的计算能力。

补充一下：这种奇怪的音高大小可能只是NPP中的一个bug。你永远不知道。

- Marco13

---

哇，这不是JCuda先生本人吗！（您在这里的论坛上是SirM2X！:D）感谢您的实验和（像往常一样）精确阐述。它真的帮了很多忙，并提供了很好的见解。 - Maghoumi

音高永远不应该是手动分配的东西。它总是应该由适当的API调用返回，进行音高分配，并且在访问该分配时将使用该音高进行未来调用。这种反向工程，虽然可能有趣，但不应该用于替代正确的音高方法/利用。通过“反向工程”，我只是指试图推断出一个基础公式，然后用它来代替正确的方法。 - Robert Crovella

在(Sir)M2X: 想到了;-) @RobertCrovella 当我说（两次）音高可能取决于黑匣子的内部细节时，这就是我试图强调的。我认为可能存在计算音高规则的情况。例如，nppiMalloc调用可以指定“音高将是w*elementsSize*componentSize，四舍五入到SMP每个核心数的下一个倍数”，等等。它也可以由cudaDeviceProps提供。然后，人们可以手动查询此信息，并手动计算音高。但是，在这里，情况并非如此... - Marco13

@RobertCrovella 实际上我没有手动设置任何音高。我关心的唯一原因是，我想简单地检查分配音高内存（因此调用cudaMallocPitch而不是调用cudaMalloc）的“机会”。如果我知道何时使用任何一个，那么我就不需要担心其他任何事情。如果我知道对于给定的宽度，NPP将分配音高内存，那么我将使用cudaMallocPitch自己分配音高内存。 - Maghoumi

@RobertCrovella 另一方面，似乎cudaMallocPitch和nppiMalloc使用不同的间距公式，如果我的分配是使用cudaMallocPitch完成的，我无法保证在NPP上的性能。 - Maghoumi

Answer 2

我想提供其他几种分配类型的列表。 我正在使用带有cuda版本7.5的GTX 860M。

cudaMallocPitch对齐到textureAlignment属性，而不是我所怀疑的texturePitchAlignment。 nppi mallocs也会对齐到textureAlignment边界，但有时会过度分配并提前跳转到下一个512字节。

由于所有这些函数将每行对齐到textureAlignment而不是更小的texturePitchAlignment，因此使用了更多的空间，但纹理应该能够绑定到任何起始行，而无需使用字节偏移进行地址计算。 文档可能对纹理不清楚，但事实证明，它们需要一行pitch是32的倍数（在这一代硬件上，texturePitchAlignment属性），起始点的地址必须是128、256或512的倍数，具体取决于硬件和cuda版本（textureAlignment）。 纹理可能能够绑定到更小的倍数，而在找到正确的属性之前，我的经验是256字节对齐似乎可以正常工作。

512字节对齐相当大，但使用texturePitchAlignment值可能会为纹理和非纹理带来性能提升。我没有进行任何测试。为了未来的保障，建议使用cudaMallocPitch或nppiMalloc，但如果内存空间紧张，可以手动使用texturePitchAlignment进行分配（如果使用纹理）。通过PCI总线的内存带宽应该不会受到更大的pitch的影响，前提是您正在使用cudaMemcpy2D或类似的函数。我建议使用Nvidia函数在PCI总线上复制分配内存。如果它们还没有高度优化并使用DMA控制器，他们最终会实现它。对于较小的pitch，可能更节省内存的方式是通过带有填充的PCI总线批量传输进行复制，但这需要测试和潜在的CPU去填充。我想知道Nvidia函数是否会在传输之前在GPU上去填充？还是逐行DMA传输？也许如果他们还没有这样做的话，最终会这样做。

int main(int argc, char **argv)
{
    void *dmem;
    int pitch, pitchOld = 0;
    size_t pitch2;
    int iOld = 0;
    int maxAllocation = 5000;

    cudaDeviceProp prop;

    cudaGetDeviceProperties(&prop, 0);      

    printf("%s%d%s%d%s", "textureAlignment ", prop.textureAlignment, " texturePitchAlignment ", prop.texturePitchAlignment, "\n");

    printf("%s", "cudaMallocPitch\n");

    for (int i=0;i<maxAllocation;++i) {
        cudaMallocPitch(&dmem, &pitch2, i, 1);

        if (pitch2 != pitchOld && i!= 0) {
            printf("%s%d%s%d%s%d%s", "width ", iOld, "to", i-1, " -> pitch ", pitchOld, "\n");
            pitchOld = pitch2;
            iOld = i;
        }

        cudaFree(dmem);
    }
    pitchOld = 0;

    printf("%s", "nppiMalloc_8u_C1\n");

    for (int i=0;i<maxAllocation/sizeof(Npp8u);++i) {
        dmem = nppiMalloc_8u_C1(i, 1, &pitch);

        if (pitch != pitchOld && i!= 0) {
            printf("%s%d%s%d%s%d%s", "width ", iOld, "to", i-1, " -> pitch ", pitchOld, "\n");
            pitchOld = pitch;
            iOld = i;
        }

        cudaFree(dmem);
    }
    pitchOld = 0;

    printf("%s", "nppiMalloc_32f_C1\n");

    for (int i=0;i<maxAllocation/sizeof(Npp32f);++i) {
        dmem = nppiMalloc_32f_C1(i, 1, &pitch);

        if (pitch != pitchOld && i!= 0) {
            printf("%s%d%s%d%s%d%s", "width ", iOld, "to", i-1, " -> pitch ", pitchOld, "\n");
            pitchOld = pitch;
            iOld = i;
        }

        cudaFree(dmem);
    }
    pitchOld = 0;

    return 0;
}

和输出

textureAlignment 512 texturePitchAlignment 32
cudaMallocPitch
width 0to0 -> pitch 0
width 1to512 -> pitch 512
width 513to1024 -> pitch 1024
width 1025to1536 -> pitch 1536
width 1537to2048 -> pitch 2048
width 2049to2560 -> pitch 2560
width 2561to3072 -> pitch 3072
width 3073to3584 -> pitch 3584
width 3585to4096 -> pitch 4096
width 4097to4608 -> pitch 4608
nppiMalloc_8u_C1
width 0to0 -> pitch 0
width 1to480 -> pitch 512
width 481to992 -> pitch 1024
width 993to1536 -> pitch 1536
width 1537to2016 -> pitch 2048
width 2017to2560 -> pitch 2560
width 2561to3072 -> pitch 3072
width 3073to3584 -> pitch 3584
width 3585to4064 -> pitch 4096
width 4065to4608 -> pitch 4608
nppiMalloc_32f_C1
width 0to0 -> pitch 0
width 1to120 -> pitch 512
width 121to248 -> pitch 1024
width 249to384 -> pitch 1536
width 385to504 -> pitch 2048
width 505to640 -> pitch 2560
width 641to768 -> pitch 3072
width 769to896 -> pitch 3584
width 897to1016 -> pitch 4096
width 1017to1152 -> pitch 4608

- Jonathan Olson