opengl - 我是否应该在统一缓冲区或着色器存储缓冲区对象内使用 `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元素 vector 类型都不存在。这包括具有3行的列主矩阵或具有3列的行主矩阵。假设唯一的类型是标量，2和4个元素 vector (和矩阵)。如果这样做，您将为自己节省很多悲痛。

如果要使用vec3 +浮点效果，则应手动打包:

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

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

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

您应该避免使用 vec3的原因有两个:

它不会做C / C++的工作

如果使用 std140布局，则可能要用C或C++定义与GLSL中的定义匹配的数据结构。这使得两者之间的混合和匹配变得容易。而且 std140布局在大多数情况下至少可以做到这一点。但是，就 vec3而言，其布局规则与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++编译器上， sizeof和 Block_a的 Block_f将均为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。

或者，您不能只在着色器中使用 vec3，而避免所有这些增加的复杂性。

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

实施支持模糊

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

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

请注意，对于Vulkan(以及使用SPIR-V的OpenGL)，SDK的GLSL编译器可以实现此目的，因此您不必为此担心。