UBO with vec3, mat33 under std140 layout question

OpenGL OpenGL: Basic Coding
1

Hello,

I’ve read (ie here) that we should forget about vec3 and mat33 for UBO std140 layouts.

I understand that the difficult part is to align things correctly, which I did.

But the most important thing seems that some OpenGL implementations are wrong ? Is it (still) true ? Do you have any information on which hardware, GL implementation this is wrong ?
Regarding to this disccussion, it seems that this is mostly related to driver bugs, which should have been fixed (or should be fixed one day). Am I right ?

The most important thing I want to know is that if I am safe to use vec3 and mat3 with UBO and std140 layouts as long as my C++ implementation is respectful to the std140 standard ?

Thanks in advance.

2

I see no advantage in taking the chance.

If you do everything std140 says you have to do to make vec3-like types work, you won’t gain anything compared with what you might get if you used vec4s and so forth. You won’t be able to “reclaim” any storage or make your structs smaller.

For example, if you have a vec3 followed by a float, the combined entity would take up only 4 floats worth of storage. But you could combine that into a vec4 and keep the exact same layout. The only difference is that you access the vec3 part with value.xyz and the float part with value.w, but that is a pretty trivial thing.

There’s no objective advantage to using vec3-like types in buffer-backed interface blocks compared to vec4s. So why take the chance that the implementation might get it wrong?

If the only thing you are concerned about is driver bugs, you can precompile your shaders into SPIR-V (assuming your implementation supports SPIR-V shaders), where you are only dealing with one compiler. In SPIR-V, all layouts have to be explicit, so the GLSL-to-SPIR-V compiler has to add the layout information, effectively implementing std140 offsetting logic for you. And even if it gets it wrong, glslang is open-source, so you can fix it (or at least, file an issue on it).

3

My C+±side implementation of vec3 and mat3 are not std140 compatible. Therefore I have an intermediate representation that fulfills this standard.

I understand that I could freely win a float for each vec3, and so 3 floats for a mat3. This is indeed interesting. However I’m not at this point now: managing “empty” 4-bytes locations (locations unused by using a vec4 from a vec3 request) will certainly be an improvement I’ll do later.

At the point I am right now, I wanted to be sure if I’ll be safe (GL-implementation talking) if I respect the std140 layout. What I currently understand from this is that std140 is a well-defined layout standard. So if I follow it strictly, hardware/drivers were my program will not work due to disalignments with vec3 and mat3 could safely be considered buggy. This leads me to the question: does this happen often ? What hardware are impacted ? Are most impacted drivers fixed ?

Thank you for the links, they look precious.