These additional types were added to provide direct type mapping between actual input vertex types and their corresponding type inside a Metal shader. Given Metal does not support as many implicit type conversions as Metal, it is more convenient and optimal to allow data to be directly passed.

Two use-cases for this are in the edit_mesh_vert shader. Where input vertex data can be in several forms, but is used as follows in the Geometry shader alternative path (not included in this PR):

.vertex_in(0, Type::VEC3, "pos")
.vertex_in(1, Type::UCHAR4, "data")
 .vertex_in(2, Type::VEC3_101010I2, "vnor")

or

.vertex_in(0, Type::VEC3, "pos")
.vertex_in(1, Type::UCHAR4, "data")
.vertex_in(2, Type::VEC3, "vnor")

vs original:

.vertex_in(0, Type::VEC3, "pos")
.vertex_in(1, Type::IVEC4, "data")
.vertex_in(2, Type::VEC3, "vnor")

For the "data" vertex attributes, these are often encoded as a UChar4 in the vertex format:

GPU_vertformat_attr_add(&format, "data", GPU_COMP_U8, 4, GPU_FETCH_INT);

Conversion from a UChar4 vertex attribute input data to a UInt4 vertex attribute in the shader is invalid in Metal via implicit conversion. Therefore, under the Metal path, changing the input type in the Shader create info to UCHAR4 allows us to directly read that data as-is.

The GLSL path then has a macro to map char types to integer types, such that implicit shader conversion still works in the same way as the original version. e.g. #define uchar4 uvec4

This could likely be handled in a different way, and a number of these types were added for thoroughness, though given these are not supported by GLSL directly, perhaps a different approach is best.

It's also worth noting that vec3_1010102_Inorm is also not a valid literal type in Metal, but this was a type alias, again converted back by macro, to explicitly allow direct data mapping, specifically in this case for SSBO vertex fetch, which needs to interpret a compressed vector manually.

In GLSL, this macro converted the type directly to vec3, to allow implicit vertex assembly to populate the values:
#define vec3_1010102_Inorm vec3

For Metal, this instead uses an int as a backing store in the shader, and a special vertex attribute read routine to unpack into a vec3 during ssbo vertex fetch, as vertex assembly isn't used in this mode:
#define vec3_1010102_Inorm int

Okay, I don't have issue with them being added. But it might be confusing for user of the API as these are reserved for internal Metal backend usage. Make sure to make that clear inside enum class Type by separating the new types with a comment.

We might use them directly in the future if they prove to reduce code complexity.

Following separate discussions on BlenderChat and to make a more permanent note here, the overall geometry shader alternative path could certainly be done in another way.

In this case, the Create-info change is to register the data which would be specified in the current:
#pragma USE_SSBO_VERTEX_FETCH(TriangleList, 3) which aims to match the geometry shader declaration.

Though it was a slight oversight of me not completely remove the other path for detecting the pragma string.

These data points aim to match the same input as the geometry shader. The aim is that for each input primitive, we specify the type of output primitive and number of desired output vertices.

i.e. for 3D poly line, to take an example where your input primitive type is LineList. To generate a wide line using a quad, we would use TriangleList as the output primitive type, and specify 6 vertices to create two triangles per input line. Under the hood, when this draw call is executed, rather than executing a line draw, the backend will execute a draw using TriangleList and multiply the output vertices by the number of input primitives to invoke that many instances of the vertex shader.
(So if we had a wide line with 6 line primitives, we would end up invoking a TriangleList draw call with 36 vertices instead).

There are other cases such as Workbench shadows where the output vertex count can be up to 12 vertices at most.

However, yes, at the moment, use of this line implies use of SSBO vertex fetch mode being enabled, in much the same way as if .geometry_layout( or .geometry_source( are specified.

Happy to either add an explicit create-info line to enable this, or also add a boolean param to specify whether it is enabled if this is preferred?

Since the shaders are different implementation alltogether, I would like to have different create infos. The workaround one should replace the standard one just like that draw_modelmat = draw_modelmat_legacy; in gpu_shader_create_info.cc.

So the create_info API should not have any change to support this.

Right, so currently they do have different create info's (again not included in this PR), though like with geometry shaders, those new create-info's require some configuration to declare how the SSBO vertex fetch mode invokes a draw.

I can remove these configurations in gpu_shader_create_info.cc if this is not desired, though this would mean needing to use something like the existing pragma inside the non-geometry-shader variant of the source:
#pragma USE_SSBO_VERTEX_FETCH(TriangleList, 3)

For a little bit of context, this is an example of create info for gpu_shader_3D_polyline using a non-geometry-shader variant which relies on SSBO vertex fetch:

GPU_SHADER_CREATE_INFO(gpu_shader_3D_polyline)
    .define("SMOOTH_WIDTH", "1.0")
    .push_constant(Type::MAT4, "ModelViewProjectionMatrix")
    .push_constant(Type::VEC2, "viewportSize")
    .push_constant(Type::FLOAT, "lineWidth")
    .push_constant(Type::BOOL, "lineSmooth")
    .vertex_in(0, Type::VEC3, "pos")
    .vertex_out(gpu_shader_3D_polyline_iface)
    .geometry_layout(PrimitiveIn::LINES, PrimitiveOut::TRIANGLE_STRIP, 4)
    .geometry_out(gpu_shader_3D_polyline_iface)
    .fragment_out(0, Type::VEC4, "fragColor")
    .vertex_source("gpu_shader_3D_polyline_vert.glsl")
    .geometry_source("gpu_shader_3D_polyline_geom.glsl")
    .fragment_source("gpu_shader_3D_polyline_frag.glsl")
    .additional_info("gpu_srgb_to_framebuffer_space");

GPU_SHADER_CREATE_INFO(gpu_shader_3D_polyline_no_geom)
    .define("SMOOTH_WIDTH", "1.0")
    .push_constant(Type::MAT4, "ModelViewProjectionMatrix")
    .push_constant(Type::VEC2, "viewportSize")
    .push_constant(Type::FLOAT, "lineWidth")
    .push_constant(Type::BOOL, "lineSmooth")
    .vertex_in(0, Type::VEC3, "pos")
    .vertex_out(gpu_shader_3D_polyline_iface)
    .ssbo_vertex_fetch_out(PrimitiveOut::TRIANGLES, 6)
    .fragment_out(0, Type::VEC4, "fragColor")
    .vertex_source("gpu_shader_3D_polyline_vert_no_geom.glsl")
    .fragment_source("gpu_shader_3D_polyline_frag.glsl")
    .additional_info("gpu_srgb_to_framebuffer_space");

Perhaps best to remove this from this PR anyhow, and instead use a future PR which has a little more context for this solution?