总的来说，答案是是的，GLM 非常适合使用 Apple 的 Metal 的应用程序。但是，有几件事需要考虑。其中一些已经在 cmets 中有所暗示。
首先，Metal Programming Guide 提到了这一点
Metal 将其归一化设备坐标 (NDC) 系统定义为 2x2x1 立方体，其中心位于 (0, 0, 0.5)
这意味着 Metal NDC 坐标与 OpenGL NDC 坐标不同，因为 OpenGL 将 NDC 坐标系定义为一个 2x2x2 立方体，其中心位于 (0, 0, 0)，即有效的 OpenGL NDC 坐标必须在其范围内
// Valid OpenGL NDC coordinates
-1 <= x <= 1
-1 <= y <= 1
-1 <= z <= 1
因为 GLM 最初是为 OpenGL 量身定制的，所以它的 glm::ortho 和 glm::perspective 函数会创建将坐标转换为 OpenGL NDC 坐标的投影矩阵。因此，有必要将这些坐标调整为金属。 this 博客文章中概述了如何实现这一点。
但是，有一种更优雅的方法可以修复这些坐标。有趣的是，Vulkan 使用与 Metal 相同的 NDC 坐标系，而 GLM 已经适应了与 Vulkan 一起使用（发现 here 的提示）。
通过定义 C/C++ 预处理器宏GLM_FORCE_DEPTH_ZERO_TO_ONE，上述 GLM 投影矩阵函数将转换坐标以使用 Metal 的 / Vulkan 的 NDC 坐标系。 #define 将因此解决不同 NDC 坐标系的问题。
接下来，在 Metal 着色器和客户端 (CPU) 代码之间交换数据时，必须同时考虑 GLM 和 Metal 数据类型的大小和对齐方式。 Apple 的 Metal Shading Language Specification 列出了 一些 其数据类型的大小和对齐方式。
对于其中未列出的数据类型，大小和对齐方式可以通过使用 C/C++ 的 sizeof 和 alignof 运算符来确定。有趣的是，Metal 着色器支持这两个运算符。以下是 GLM 和 Metal 的几个示例：
// Size and alignment of some GLM example data types
glm::vec2 : size: 8, alignment: 4
glm::vec3 : size: 12, alignment: 4
glm::vec4 : size: 16, alignment: 4
glm::mat4 : size: 64, alignment: 4
// Size and alignment of some of Metal example data types
float2 : size: 8, alignment: 8
float3 : size: 16, alignment: 16
float4 : size: 16, alignment: 16
float4x4 : size: 64, alignment: 16
packed_float2 : size: 8, alignment: 4
packed_float3 : size: 12, alignment: 4
packed_float4 : size: 16, alignment: 4
从上表中可以看出，GLM 矢量数据类型在大小和对齐方面都与 Metal 的打包矢量数据类型非常匹配。但请注意，4x4 矩阵数据类型在对齐方面不匹配。
根据this对另一个SO问题的回答，对齐的含义如下：
对齐是对可以存储值的第一个字节的内存位置的限制。 （需要提高处理器的性能并允许使用某些指令，这些指令仅适用于具有特定对齐方式的数据，例如 SSE 需要对齐到 16 字节，而 AVX 需要对齐到 32 字节。）
16 对齐意味着只有 16 的倍数的内存地址是唯一有效的地址。
因此，在将 4x4 矩阵发送到金属着色器时，我们需要小心考虑不同的对齐方式。我们来看一个例子：
以下 Objective-C 结构用作缓冲区，用于存储要发送到 Metal 顶点着色器的统一值：
typedef struct
{
glm::mat4 modelViewProjectionMatrix;
glm::vec2 windowScale;
glm::vec4 edgeColor;
glm::vec4 selectionColor;
} SolidWireframeUniforms;
这个结构定义在一个头文件中，该头文件包含在客户端（即 CPU 端）代码中任何需要它的地方。为了能够在 Metal 顶点着色器端使用这些值，我们需要一个相应的数据结构。在此示例中，Metal 顶点着色器部分如下所示：
#include <metal_matrix>
#include <metal_stdlib>
using namespace metal;
struct SolidWireframeUniforms
{
float4x4 modelViewProjectionMatrix;
packed_float2 windowScale;
packed_float4 edgeColor;
packed_float4 selectionColor;
};
// VertexShaderInput struct defined here...
// VertexShaderOutput struct defined here...
vertex VertexShaderOutput solidWireframeVertexShader(VertexShaderInput input [[stage_in]], constant SolidWireframeUniforms &uniforms [[buffer(1)]])
{
VertexShaderOutput output;
// vertex shader code
}
为了将数据从客户端代码传输到 Metal 着色器，统一结构被打包到缓冲区中。以下代码显示了如何创建和更新该缓冲区：
- (void)createUniformBuffer
{
_uniformBuffer = [self.device newBufferWithBytes:(void*)&_uniformData length:sizeof(SolidWireframeUniforms) options:MTLResourceCPUCacheModeDefaultCache];
}
- (void)updateUniforms
{
dispatch_semaphore_wait(_bufferAccessSemaphore, DISPATCH_TIME_FOREVER);
SolidWireframeUniforms* uniformBufferContent = (SolidWireframeUniforms*)[_uniformBuffer contents];
memcpy(uniformBufferContent, &_uniformData, sizeof(SolidWireframeUniforms));
dispatch_semaphore_signal(_bufferAccessSemaphore);
}
注意用于更新缓冲区的memcpy 调用。如果 GLM 和 Metal 数据类型的大小和对齐方式不匹配，就会出现问题。由于我们只是简单地将 Objective-C 结构的每个字节复制到缓冲区，然后在 Metal 着色器端，再次解释该数据，如果数据结构不匹配，数据将在 Metal 着色器端被误解。
在该示例中，内存布局如下所示：
104 bytes
|<--------------------------------------------------------------------------->|
| |
| 64 bytes 8 bytes 16 bytes 16 bytes |
| modelViewProjectionMatrix windowScale edgeColor selectionColor |
|<------------------------->|<----------->|<--------------->|<--------------->|
| | | | |
+--+--+--+------------+--+--+--+-------+--+--+-----------+--+--+----------+---+
Byte index | 0| 1| 2| ... |62|63|64| ... |71|72| ... |87|88| ... |103|
+--+--+--+------------+--+--+--+-------+--+--+-----------+--+--+----------+---+
^ ^ ^
| | |
| | +-- Is a multiple of 4, aligns with glm::vec4 / packed_float4
| |
| +-- Is a multiple of 4, aligns with glm::vec4 / packed_float4
|
+-- Is a multiple of 4, aligns with glm::vec2 / packed_float2
除了 4x4 矩阵对齐之外，一切都匹配得很好。 4x4 矩阵的错位在这里没有问题，如上述内存布局所示。但是，如果统一结构被修改，对齐或大小可能会成为问题，并且可能需要填充才能使其正常工作。
最后，还有一点需要注意。数据类型的对齐对需要分配给统一缓冲区的大小有影响。因为SolidWireframeUniforms结构中出现的最大对齐是16，看来uniform缓冲区的长度也必须是16的倍数。
在上面的示例中情况并非如此，缓冲区长度为 104 字节，不是 16 的倍数。直接从 Xcode 运行应用程序时，内置断言会打印以下消息：
validateFunctionArguments:3478: 断言失败`Vertex Function(solidWireframeVertexShader): 来自缓冲区(1) 的参数uniforms[0] 偏移量(0) 和长度(104) 有104 个字节的空间，但参数有一个长度(112) .'
为了解决这个问题，我们需要将缓冲区的大小设置为 16 字节的倍数。为此，我们只需根据我们需要的实际长度计算下一个 16 的倍数。对于 104 来说就是 112，这也是上面的断言也告诉我们的。
以下函数计算指定整数的下一个 16 的倍数：
- (NSUInteger)roundUpToNextMultipleOf16:(NSUInteger)number
{
NSUInteger remainder = number % 16;
if(remainder == 0)
{
return number;
}
return number + 16 - remainder;
}
现在我们使用上面的函数计算统一缓冲区的长度，它改变了缓冲区创建方法（上面发布）如下：
- (void)createUniformBuffer
{
NSUInteger bufferLength = [self roundUpToNextMultipleOf16:sizeof(SolidWireframeUniforms)];
_uniformBuffer = [self.device newBufferWithBytes:(void*)&_uniformData length:bufferLength options:MTLResourceCPUCacheModeDefaultCache];
}
这应该可以解决上述断言检测到的问题。