为什么 glTextureStorage*D 函数会消耗这么多内存？ opengl实际上做了什么？

Question

// test data brick
class Brick
{
public:
    Brick() { data = new U32[27]; }
    virtual ~Brick() { delete[] data; }

    U32* data;
};

Texture3D* OctreeMipmapper::GenerateBrickTexture()
{
    auto ret = new Texture3D();
    ret->Initialize();
    ret->Storage(GL_R32UI, SV3(g_brickSize)); // g_brickSize = 3u, SV3 is a 3d-signed-int-vec
    ret->SetScaleFilter(GL_LINEAR, GL_LINEAR);
    ret->SetWrapFilter(GL_CLAMP_TO_BORDER);
    ret->SetBorderColorIiv(SV4{ 0u, 0u, 0u, 0u });
    //ret->GenerateBindlessImageHandle(GL_R32UI);
    return ret;
}

void OctreeMipmapper::InitOctreeBrick()
{
    auto texNum = m_octree->GetTexNum(); // texNum = 600000u
    m_albedoBricks.resize(texNum);
    m_normalBricks.resize(texNum);
    m_bricks.resize(texNum);
    for (U32 i = 0u; i < texNum; ++i)
    {
        m_bricks[i] = new Brick();
        m_albedoBricks[i] = GenerateBrickTexture();
        //m_normalBricks[i] = GenerateBrickTexture();
    }
}

上面是我的源码，可以看到，bricks向量的数量是600000，贴图是3d单通道贴图，27 texel(3 * 3 * 3)。因此，数据大小为 600000 * 27 * 4 字节 = 64MB。但是当我运行代码时，这些纹理的内存使用量超过 3GB，这让我很困惑。我想要opengl在glTextureStorage3D函数中做了什么

Answer 1

纹理是具有 27 texel(3 * 3 * 3) 的 3d 单通道纹理。

从技术上讲，这是系统存储此类纹理可能需要的最小存储空间。

这并不意味着这是纹理实际消耗的内存量。即使忽略我现在将讨论的任何特定细节，这 600,000 个纹理中的每一个都需要存储关于这些纹理的信息。 GPU 需要访问的存储：过滤参数、纹理大小、mipmap 限制等。因为 GPU 需要这些数据，所以这些数据需要（至少）存在于 GPU 可访问的存储中。

但还有更多。为了以最佳方式从纹理中选择纹素，硬件将采用所谓的混合。虽然不同的硬件以不同的方式执行此操作，但基本思想是提高访问的局部性。如果一个片段访问坐标 X、Y、Z 处的纹素，那么一个片段很可能访问 X、Y+1、Z 或类似的东西。所以系统会混淆纹素在分配的存储空间中的位置来完成这项工作。

Swizzling 通常需要在纹理尺寸上进行一些最小对齐。每个轴可以小到 4 个，也可以大到 32-64。

此外，纹理内存往往必须以某种方式对齐。也就是说，纹理的起始字节必须与某个最小对齐方式对齐。这可能小至 32 字节，也可能大至完整内存页面 (4K) 或更多，具体取决于实现。

因此，这些纹理中的每一个完全有可能在实际存储中占用 4KB 或更多。这与您正在使用的存储量非常接近。

你应该找到避免使用微小纹理的方法。

请注意，Vulkan 作为较低级别的 API，可让您了解最小对齐、大小等信息。因此，您可以通过尝试创建这些纹理之一来判断它需要多少实际存储空间。