Results 1 to 3 of 3

Thread: UBO with vec3, mat33 under std140 layout question

  1. #1
    Junior Member Newbie
    Join Date
    Oct 2018

    UBO with vec3, mat33 under std140 layout question


    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. #2
    Senior Member OpenGL Lord
    Join Date
    Mar 2015
    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 `vec4`s 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 `` 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 `vec4`s. 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. #3
    Junior Member Newbie
    Join Date
    Oct 2018
    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.

Similar Threads

  1. Problem with layout std140 and binding
    By manuel_p in forum OpenGL: Basic Coding
    Replies: 2
    Last Post: 12-01-2016, 04:28 PM
  2. std140 layout
    By t_guen03 in forum OpenGL: Advanced Coding
    Replies: 5
    Last Post: 04-21-2014, 02:26 PM
  3. NVIDIA 310.70 std140 layout bug in SSBO
    By randall in forum OpenGL: Drivers
    Replies: 0
    Last Post: 01-04-2013, 08:42 AM
  4. Nvidia dmat3x4 in std140 UBO layout
    By anisotropic in forum OpenGL: Drivers
    Replies: 0
    Last Post: 06-17-2011, 11:25 AM
  5. layout(std140) help needed
    By BrianDFS in forum OpenGL: Advanced Coding
    Replies: 6
    Last Post: 03-28-2010, 06:41 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
Proudly hosted by Digital Ocean