问题标签 [metal]

有一篇文章声称 Metal 可以比 Accelerate 框架更快地计算大量数字。

在查看了 Metal 的着色器语言的文档后，我意识到不支持双精度浮点数或 64 位整数数组。我忽略了什么吗？我以为 Metal 是为 64 位 A7 处理器设计的？

我需要从MTLBufferGPU 上的后处理中读取数据。到目前为止，我已经尝试过以下代码，但它总是因EXC_BAD_ACCESS错误代码而崩溃。

我也尝试过不同的方法来获得价值，比如

或者

但他们都没有工作。有没有办法做到这一点？

我想将写入同步到MTLBufferMetal 内核中的线程组之间。我尝试使用atomic_uint类型和atomic_fetch_add_explicit功能。这应该可行，但我的问题是我不知道如何解释 CPU 端的值。我更喜欢一种锁定机制，我可以使用它来同步从不同线程组对同一缓冲区的写入。是否有这种机制或其他一些不受原子类型约束的解决方法？

我刚刚深入研究了金属世界，我以为我已经掌握了窍门！但后来我突然想到，如果我想制作一款游戏，那么在屏幕上移动的静态对象是不够的。所以我的问题是，'是否可以使用 Metal 为模型创建动画？

我曾研究过使用其他 API，例如 SpriteKit 和 SceneKit，但我发现它们不支持着色器，并且不如 Metal 强大。

我能想到的唯一方法是创建 60 个不同的模型，然后一个接一个地加载每个模型，以产生“定格”效果，但我认为这会可能效率极低，并希望有一个更简单的答案？

非常感谢！

我正在开发一个针对 iOS 5.1.1 到 iOS 8 的应用程序。它是一个包含 arm64、armv7 和 armv7s 的通用二进制文件。现在，arm64 将在 iOS 7 及更高版本（在受支持的设备上）上加载，但我想强制它仅在 iOS 8 上加载（即，使 iOS 7 恢复为加载 armv7s）。

动机：出于效率原因，我需要对某些 ​​iOS 8 特定功能进行条件编译。我正在将整个渲染后端从 OpenGL ES 切换到 iOS 8 上的 Metal，并且不想为两者之间的任何动态调度付费。后端是一堆 c 函数，因此动态选择 API 需要为所有内容添加一层额外的函数指针。如果 arm64 只有 iOS 8，我可以有条件地使用#ifdef __arm64__.

我认为可能有效的方法：我在“iOS 部署目标”下为 arm64 添加了条件构建设置。我检查了构建日志，看到它-miphoneos-version-min=8.0是为 arm64 构建添加的。它在 iOS 8 和 arm64 上运行良好。对于 iOS 7 和 arm64，我看到了两种可能的结果；1) iOS 7 查看 64 位二进制文​​件，将其视为不受支持而丢弃，然后继续加载 armv7s。2) 尝试加载 64 位二进制文​​件并崩溃。问题是我唯一的 64 位设备运行 iOS 8，所以我无法对其进行测试。

我的问题是这是否可行（也许以前有人尝试过），或者是否有其他解决方案。

条件构建设置的屏幕截图以供参考：

我正在尝试使用 Metal API 在 Apple A7 GPU 上尽可能快地渲染大量非常小的 2D 四边形。研究 GPU 的三角形吞吐量数字，例如这里，以及 Apple 在其主题演示期间在屏幕上引用 >1M 三角形，我希望能够以 60fps 的速度每帧渲染 500,000 个这样的四边形。考虑到它们都是可见的（在屏幕上，不被 z 缓冲区隐藏）和微小的（对于光栅化器来说很棘手），可能会少一些，所以这可能不是 GPU 超级优化的用例。也许那个 Apple 演示以 30fps 运行，所以假设大约 200,000 应该是可行的。当然是 100,000 ……对吧？

然而，在我的测试应用程序中，最大值仅为 20,000 左右——超过此值，并且 iPad Air 上的帧速率降至 60 以下。使用 100,000 个四边形，它以 14 fps 的速度运行，即吞吐量为 2.8M 三角形/秒（与 AnandTech 文章中引用的 68.1M屏幕三角形相比！）。

即使我将四边形缩小为单个像素，使用微不足道的片段着色器，性能也不会提高。所以我们可以假设这是顶点绑定，并且 Xcode 中的 GPU 报告同意（“Tiler”为 100%）。顶点着色器也很简单，除了一点缩放和平移数学什么都不做，所以我假设瓶颈是一些固定功能阶段......？

只是为了获得更多背景信息，我使用单个实例绘制调用渲染所有几何图形，每个实例一个四边形，即每个实例 4 个顶点。四边形的位置是从一个单独的缓冲区应用的，该缓冲区由顶点着色器中的实例 id 索引。我也尝试了其他一些方法（非实例化，所有顶点都预先转换，实例化+索引等），但这没有帮助。没有复杂的顶点属性、缓冲区/表面格式或我能想到的任何其他东西似乎可能会在驱动程序/GPU 中遇到缓慢的路径（尽管我当然不能确定）。混合已关闭。几乎所有其他东西都处于默认状态（视口、剪刀、ztest、剔除等）。

该应用程序是用 Swift 编写的，但希望这无关紧要；）

我想了解的是，在渲染这样的四边形（而不是“适当的”3d 场景）时，我所看到的性能是否是预期的，或者是否需要一些更先进的技术来接近广告三角形吞吐量。人们认为这里的限制瓶颈可能是什么？

另外，如果有人知道为什么这在 OpenGL 中可能比在 Metal 中更快（我没有尝试过，也想不出任何原因），那么我也很想听听。

谢谢

编辑：添加着色器代码。

由于 Metal Language 也是基于 C++11，而 C++ 似乎是一种经过验证的性能语言的完美契合，我希望完全绕过 Objective-C / Swift。我很想留在 C++ 领域。有没有可能？

我想使用 Metal 作为计算 API（因为 iOS 仍然不支持 ES 3.1 计算着色器）和 OpenGL ES 作为图形 API 来移植一些 OpenCL 示例，因为示例使用 OCL/OGL 互操作似乎是最简单的移植方式。问题是应用程序可以同时使用 Metal 和 OpenGL ES API，以及是否以及如何实现互操作，即 OpenGL 映射由 Metal 计算的数据缓冲区对象.. 谢谢..

我一直在构建 2D 游戏，并且一直在子类中绘制游戏区域，在该UIView子类中我覆盖drawRect:并使用大量UIBezierPath*对象绘制游戏。我在 iOS 上不是很有经验，我一直想知道这是否是正确的方法。

所以我想我的问题是多少才够？我应该何时停止使用UIBezierPath并开始使用 OpenGL 或 Metal？我可以使用它们在内部绘图UIView还是完全控制屏幕？

所以我正在做一个跨平台的视频游戏……因此，我需要能够在 windows 平台上使用 DirectX，在 mac、linux 和 android 平台上使用 OpenGL/ES，以及在 iOS 平台上使用 Metal。我搜索了库，但找不到任何东西，所以，我决定创建自己的 typedef，它将是宏控制的，例如，我将 COLOR 定义为 Windows 平台上的 D3DColor，iPhone 平台上的 UIColor , 和 glColor4f 在其他符合 GL 的平台上。这是 iOS 平台的函数所在的头文件 (CommonMetal.h)：

这是 obj-c 源文​​件 (CommonMetal.m) 中的代码：

注意：Metal 是我创建的预定义宏，以确保这是一个兼容 metal 的平台，并且代码已放置在 Precompiled Header 中。

当我尝试编译项目时，我收到指向 typedef 行的头文件的错误。这是确切的错误：

.../CommonMetal.h:13:9：未知类型名称“UIColor”

.../CommonMetal.h:14:9: 未知类型名称 'GLKVector3'

.../CommonMetal.h:15:9: 未知类型名称 'GLKVector4'

我已经阅读了有关堆栈溢出的其他答案，但是每当我尝试添加时：

出现此问题/答案中描述的错误。因此，据我了解，该文件被认为是 c++ 文件而不是 obj-c 文件。我尝试使用上面链接中建议的答案，这确实消除了错误，但之前的 UIColor 错误未定义等仍然存在。如果需要任何其他信息，请添加评论，我一定会添加额外的信息。提前致谢。