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

Posted 2023-02-22

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

【英文标题】：Should I ever use a `vec3` inside of a uniform buffer or shader storage buffer object?

【发布时间】：2016-07-03 17:46:39

【问题描述】：

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;
;

这是个好主意吗？

【参考方案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 编译器可以做到这一点，因此您无需为此担心。

【讨论】：

好吧，我最近对它进行了逆向工程，至少glslangValidator 按预期将它紧紧地打包在 SPIR-V 中（成员偏移量分别为 0、16、28）。如果它只是关于对齐，那么更好的例子是 vec3 跟随标量浮点数。

@NicolBolas 嗯，有歧义（我想你会知道的，因为我相信你开始 GitHub Issue 关于它）。在 OGL 规范中比 VK 更清楚（因为它至少定义了大多数使用的术语）我倾向于认为“前一个成员消耗的基本机器单元”仍然意味着 vec3 的 3NB（“对齐”不应该改变那 - 这不是这个词的意思）。

@AzP：std430 布局规则的唯一 变化是数组和标量结构和二元素向量的基本对齐方式。它对vec3s 没有任何改变，因为它们的基本对齐方式始终是vec4。

我在阅读这篇文章时学到的重要一点：规范允许float 在内存中紧跟vec3，因此它们总共占用16 个字节。在对齐方面，这似乎是vec3 与vec4 的主要（如果不是唯一）区别特征。 IE。 size != 基本对齐，仅适用于具有三个组件且也不是数组元素的向量。

@Tom：该答案中的所有示例都是正确的，但引用的文本不是来自 OpenGL 规范；它来自一本书。那句话是不正确的。规范指出，对于 std430，数组和结构的舍入规则不适用。但是 vec3 的问题是 not 来自舍入规则；它的对齐方式不是基于数组和结构的舍入。 vec3 的基本对齐直接指定为 16 个字节。