opengl - 我是否应该在统一缓冲区或着色器存储缓冲区对象内使用 `vec3`?

标签 opengl opengl-es glsl vulkan

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

这是一个好主意吗?

最佳答案

不! 永远不要这样做!

在声明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++编译器上,sizeofBlock_aBlock_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_aBlock_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编译器可以实现此目的,因此您不必为此担心。

关于opengl - 我是否应该在统一缓冲区或着色器存储缓冲区对象内使用 `vec3`?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/58902864/

相关文章:

glsl - webgl 着色器调试/性能/成本

opengl - GLSL 中的 HDR、自适应色调映射和 MSAA

c - NSAddImage 的替换(在 GLLoadGen 中)

c++ - OpenGL和GLSL之间的通信

c++ - 将 OpenGL 1.x 代码移植到 WebGL

Android - 在 SurfaceTexture 上绘制 YouTube 视频

c++ - 使用 Xcode 和 Eclipse 在 Mac Mojave 上编译着色器问题

opengl - 在顶点和片段着色器之间添加几何着色器时出现链接错误

java - 我可以将 GLSurface View (动画)设置为背景吗?

c++ - 当我在顶点着色器中有 "out"时,OpenGL 不绘制