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元素向量和矩阵类型不存在。假设唯一的类型是标量，2和4元素向量（和矩阵）。如果你这样做，你将为自己节省很多悲伤。

如果你想要一个vec3 +一个浮点数的效果，那么你应该手动包装它：

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

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

如果你想要vec3的数组，那么让它们成为vec4的数组。对于使用3元素向量的矩阵也是如此。从你的SSBO / UBO中消除3元素载体的整个概念;从长远来看，你会好得多。

有两个原因可以避免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的{{1}}将为24.这意味着Block_f offsetof将为12。

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

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

_Alignas

如果编译器支持16字节对齐，这将起作用。或者至少，它适用于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; };和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必须在16字节边界上启动。但vec3 消耗 16个字节的存储空间;它只消耗12.由于vec3可以从4字节边界开始，float后跟vec3将占用16个字节。

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

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

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

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

实施支持模糊

即使你做的一切都正确，但已知实现错误地实现vec2的古怪布局规则。一些实现有效地将C ++对齐规则强加给GLSL。因此，如果您使用vec3，它会将其视为C ++将处理16字节对齐类型。在这些实现中，vec3后跟vec3的工作方式类似于vec3，后跟float。

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

请注意，对于Vulkan，SDK的GLSL编译器可以正确使用，因此您无需为此担心。

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

1 个答案:

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

实施支持模糊