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++编译器上,
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编译器可以实现此目的,因此您不必为此担心。
关于opengl - 我是否应该在统一缓冲区或着色器存储缓冲区对象内使用 `vec3`?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/58902864/