我应该在统一缓冲区或着色器存储缓冲区对象中使用“vec3”吗？

Question

vec3 类型是一个非常好的类型。它只占用 3 个浮点数，而我的数据只需要 3 个浮点数。我想在 UBO 和/或 SSBO 的结构中使用一个：

layout(std140) uniform UBO
{
  vec4 data1;
  vec3 data2;
  float data3;
};

layout(std430) buffer SSBO
{
  vec4 data1;
  vec3 data2;
  float data3;
};

然后，在我的 C 或 C++ 代码中，我可以这样做来创建匹配的数据结构：

struct UBO
{
  vector4 data1;
  vector3 data2;
  float data3;
};

struct SSBO
{
  vector4 data1;
  vector3 data2;
  float data3;
};

这是个好主意吗？

Answer 1

不！永远不要这样做！

在声明 UBO/SSBO 时，假装所有 3 元素向量类型都不存在。这包括 3 行的列优先矩阵或 3 列的行优先矩阵。假设唯一的类型是标量、2 和 4 元素向量（和矩阵）。如果你这样做，你会为自己省去很多痛苦。

如果你想要 vec3 + float 的效果，那么你应该手动打包：

layout(std140) uniform UBO
{
  vec4 data1;
  vec4 data2and3;
};

是的，您必须使用data2and3.w 来获取其他值。处理它。

如果您想要vec3s 的数组，则将它们设为vec4s 的数组。使用 3 元素向量的矩阵也是如此。只需从您的 SSBO/UBO 中消除 3 元素向量的整个概念即可；从长远来看，你会过得更好。

避免vec3的原因有两个：

它不会像 C/C++ 那样做

如果您使用std140 布局，那么您可能希望在 C 或 C++ 中定义与 GLSL 中的定义相匹配的数据结构。这使得两者之间的混合和匹配变得容易。而std140 布局至少可以在大多数情况下做到这一点。但是当涉及到vec3s 时，它的布局规则与 C 和 C++ 编译器的通常布局规则不匹配。

考虑 vec3 类型的以下 C++ 定义：

struct vec3a { float a[3]; };
struct vec3f { float x, y, z; };

这两种都是完全合法的类型。这些类型的sizeof 和布局将匹配std140 所需的大小和布局。但它与std140 强加的对齐行为不匹配。

考虑一下：

//GLSL
layout(std140) uniform Block
{
    vec3 a;
    vec3 b;
} block;

//C++
struct Block_a
{
    vec3a a;
    vec3a b;
};

struct Block_f
{
    vec3f a;
    vec3f b;
};

在大多数 C++ 编译器上，Block_a 和 Block_f 的 sizeof 将为 24。这意味着 offsetof b 将为 12。

然而，在 std140 布局中，vec3 始终与 4 个字对齐。因此，Block.b 的偏移量为 16。

现在，您可以尝试使用 C++11 的 alignas 功能（或 C11 的类似 _Alignas 功能）来解决这个问题：

struct alignas(16) vec3a_16 { float a[3]; };
struct alignas(16) vec3f_16 { float x, y, z; };

struct Block_a
{
    vec3a_16 a;
    vec3a_16 b;
};

struct Block_f
{
    vec3f_16 a;
    vec3f_16 b;
};

如果编译器支持 16 字节对齐，这将起作用。或者至少，它适用于Block_a 和Block_f。

但在这种情况下它不会工作：

//GLSL
layout(std140) Block2
{
    vec3 a;
    float b;
} block2;

//C++
struct Block2_a
{
    vec3a_16 a;
    float b;
};

struct Block2_f
{
    vec3f_16 a;
    float b;
};

根据std140 的规则，每个vec3 必须开始在16 字节的边界上。但是vec3 不会消耗 16 字节的存储空间；它只消耗 12 个字节。由于 float 可以从 4 字节边界开始，vec3 后跟 float 将占用 16 个字节。

但是 C++ 对齐规则不允许这样的事情。如果一个类型与 X 字节边界对齐，那么使用该类型将消耗 X 字节的倍数。

因此，匹配std140 的布局要求您根据使用的确切位置选择类型。如果后面是float，则必须使用vec3a；如果其后跟一些超过 4 字节对齐的类型，则必须使用 vec3a_16。

或者你不能在你的着色器中使用vec3s 并避免所有这些增加的复杂性。

请注意，基于alignas(8) 的vec2 不会出现此问题。 C/C++ 结构和数组也不会使用正确的对齐说明符（尽管较小类型的数组有自己的问题）。此问题仅在使用裸vec3 时出现。

实现支持模糊

即使您做对了所有事情，但已知实现会错误地实现vec3 的古怪布局规则。一些实现有效地将 C++ 对齐规则强加给 GLSL。因此，如果您使用 vec3，它会像对待 C++ 对待 16 字节对齐类型一样对待它。在这些实现中，vec3 后跟 float 的工作方式类似于 vec4 后跟 float。

是的，这是实施者的错。但是由于您无法修复实现，因此您必须解决它。最合理的做法是完全避免使用vec3。

请注意，对于 Vulkan（和使用 SPIR-V 的 OpenGL），SDK 的 GLSL 编译器可以做到这一点，因此您无需为此担心。