42

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

这是一个好主意吗？

4

1 回答 1

68

不！永远不要这样做！

在声明 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布局至少可以做到这一点。vec3但是当涉及到s时，它的布局规则与 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都是24。这意味着将是 12。Block_aBlock_foffsetof b

然而，在 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_aand的情况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 字节边界开始，avec3后跟 afloat将占用 16 个字节。

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

因此，matchingstd140的布局要求您根据使用的确切位置选择一种类型。如果后面跟着 a float，你必须使用vec3a; 如果其后跟一些超过 4 字节对齐的类型，则必须使用vec3a_16.

或者，您可以不在vec3着色器中使用 s 并避免所有这些增加的复杂性。

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

实施支持模糊

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

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

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

于 2016-07-03T17:46:39.037 回答