#memory-layout #glsl #opengl #glsl-shader #graphics #struct-fields #memory-mapping

std140

GLSL interface block memory, layed-out according to the std140 convention, represented as Rust structs

10 releases

0.2.6 Sep 1, 2022
0.2.5 Oct 27, 2021
0.2.4 Apr 9, 2021
0.2.2 Feb 6, 2020
0.1.2 Oct 6, 2019

#469 in Graphics APIs


Used in 5 crates (4 directly)

MIT license

50KB
1K SLoC

Std140.rs

Crates.io docs.rs docs

Provides types and an attribute macro to help write Rust structs with a memory layout that matches the std140 memory layout as used for GLSL interface blocks (e.g. uniform blocks).

Please refer to the documentation for details.


lib.rs:

This module contains types that may be used to define Rust struct types that match the GLSL std140 memory layout.

Std140 is a standardized memory layout for GLSL shader interface blocks (e.g. uniform blocks). An interface block is a group op typed GLSL variables. For details on the layout rules for std140, please refer to the section 2.12.6.4 "Standard Uniform Block Layout" of the OpenGL ES 3.0 Specification.

This module aims to make it easy to construct and manipulate a block of std140 compatible memory as a Rust struct, such that the struct's memory layout will match a GLSL interface block if every block member is pairwise type-compatible with the struct field in the corresponding position. Position here relates to the order in which block members and struct fields are declared, e.g.: the 1st block member must be compatible with the 1st struct field, the 2nd block member must be compatible with the 2nd struct field, etc. The struct itself has to be marked with the #[repr_std140] attribute: this ensures the rust compiler will correctly order and align the fields.

For GLSL primitive types, compatibility is defined by the following mapping from GLSL types to std140 types:

  • float: [float]
  • vec2: [vec2]
  • vec3: [vec3]
  • vec4: [vec4]
  • mat2: [mat2x2][struct@mat2x2]
  • mat3: [mat3x3][struct@mat3x3]
  • mat4: [mat4x4][struct@mat4x4]
  • mat2x2: [mat2x2][struct@mat2x2]
  • mat2x3: [mat2x3][struct@mat2x3]
  • mat2x4: [mat2x4][struct@mat2x4]
  • mat3x2: [mat3x2][struct@mat3x2]
  • mat3x3: [mat3x3][struct@mat3x3]
  • mat3x4: [mat3x4][struct@mat3x4]
  • mat4x2: [mat4x2][struct@mat4x2]
  • mat4x3: [mat4x3][struct@mat4x3]
  • mat4x4: [mat4x4][struct@mat4x4]
  • int: [int]
  • ivec2: [ivec2]
  • ivec3: [ivec3]
  • ivec4: [ivec4]
  • uint: [uint]
  • uvec2: [uvec2]
  • uvec3: [uvec3]
  • uvec4: [uvec4]
  • bool: [boolean]
  • bvec2: [bvec2]
  • bvec3: [bvec3]
  • bvec4: [bvec4]

A GLSL struct type is compatible with a field if this field's type is a Rust struct marked with #[repr_std140] and this struct's fields are pair-wise compatible with the GLSL struct field in the corresponding position.

A GLSL array of GLSL type T with compatible type T_c (as defined above) and length N is compatible with a field of type std140::array<T_c, N>.

Example

Given the following GLSL declaration of an (uniform) interface block:

struct PointLight {
    vec3 position;
    float intensity;
}

layout(std140) uniform Uniforms {
    mat4 transform;
    vec3 ambient_light_color;
    PointLight lights[2];
}

The following will produce a Rust struct instance with a compatible memory layout:

#[std140::repr_std140]
struct PointLight {
    position: std140::vec3,
    intensity: std140::float,
}

#[std140::repr_std140]
struct Uniforms {
    transform: std140::mat4x4,
    ambient_light_color: std140::vec3,
    lights: std140::array<PointLight, 2>
}

let instance = Uniforms {
    transform: std140::mat4x4(
        std140::vec4(1.0, 0.0, 0.0, 0.0),
        std140::vec4(0.0, 1.0, 0.0, 0.0),
        std140::vec4(0.0, 0.0, 1.0, 0.0),
        std140::vec4(0.0, 0.0, 0.0, 1.0),
    ),
    ambient_light_color: std140::vec3(0.2, 0.2, 0.2),
    lights: std140::array![
        PointLight {
            position: std140::vec3(10.0, 0.0, 10.0),
            intensity: std140::float(0.5)
        },
        PointLight {
            position: std140::vec3(0.0, 10.0, 10.0),
            intensity: std140::float(0.8)
        },
    ]
};

Note that although the field names match the block member names in this example, this is not strictly necessary: only pairwise field-type compatibility is required.

Dependencies

~1.5MB
~37K SLoC