我即将将使用C ++编写的OpenGL的iOS应用程序移植到Apple的Metal。目标是完全摆脱OpenGL并用Metal替换它。
OpenGL代码是分层的，我试图只是替换渲染器，即实际调用OpenGL函数的类。但是，整个代码库使用GLM数学库来表示向量和矩阵。
例如，有一个提供视图和投影矩阵的相机类。它们都是glm::mat4类型，只是简单地传递给GLSL顶点着色器，它们与GLSL给出的mat4数据类型兼容。我想利用那个相机类将这些矩阵发送到Metal顶点着色器。现在，我不确定glm::mat4是否与Metal的float4x4兼容。
我没有一个可以测试它的工作示例，因为我刚开始使用Metal并且在网上找不到任何有用的东西。
所以我的问题如下：
glm::mat4和glm::vec4是否与Metal的float4x4 / float4兼容？关于问题2的背景是我遇到了Apple的SIMD库，它提供了另一组数据类型，在这种情况下我无法使用，对吧？
该应用程序仅适用于iOS，我根本不关心在macOS上运行Metal。
代码片段（最好是Objective-C（是的，不是开玩笑））非常受欢迎。
总的来说，答案是肯定的，GLM非常适合使用Apple的Metal的应用程序。但是，有几件事需要考虑。其中一些内容已在评论中暗示过。
首先，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坐标的投影矩阵。因此，有必要将这些坐标调整为Metal。如何实现这一点在this博客文章中有所概述。
但是，有一种更优雅的方法来修复这些坐标。有趣的是，Vulkan使用与Metal相同的NDC坐标系统，GLM已经适应与Vulkan一起使用（暗示发现here）。
通过定义C / C ++预处理器宏GLM_FORCE_DEPTH_ZERO_TO_ONE，提到的GLM投影矩阵函数将变换坐标以使用Metal的/ Vulkan的NDC坐标系。因此，#define将解决不同NDC坐标系的问题。
接下来，在金属着色器和客户端（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 shader端复制，再次解释该数据，如果数据结构不匹配，数据将在Metal shader端被误解释。
在该示例的情况下，内存布局如下所示：
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 matix对齐外，一切都很好。 4×4矩阵的未对准在此处没有问题，如上述存储器布局中可见。但是，如果统一结构被修改，则对齐或大小可能会成为问题，并且可能需要填充才能使其正常工作。
最后，还有其他一些需要注意的事项。数据类型的对齐会影响需要为统一缓冲区分配的大小。因为SolidWireframeUniforms结构中出现的最大对齐是16，所以统一缓冲区的长度似乎也必须是16的倍数。
在上面的示例中并非如此，其中缓冲区长度为104个字节，而不是16的倍数。当直接从Xcode运行应用程序时，内置断言会打印以下消息：
validateFunctionArguments：3478：断言失败`顶点函数（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];
}
这应该解决上述断言检测到的问题。