作为 iOS 框架一部分的 Metal 文件 [英] Metal file as part of an iOS framework

问题描述

我正在尝试创建一个适用于 METAL Api (iOS) 的框架.我对这个平台很陌生，我想知道如何构建框架以使用 .metal 文件(我正在构建一个静态库，而不是动态库).它们应该是 .a 文件的一部分，还是作为框架包中的资源文件?或者有其他方法可以做到这一点?谢谢.

I am trying to create a framework that works with METAL Api (iOS). I am pretty new to this platform and I would like to know how to build the framework to work with .metal files (I am building a static lib, not dynamic). Should they be a part of the .a file, or as a resource files in the framework bundle? Or is there an other way to do that? Thanks.

更新:对于那些解决这个问题的人 - 我最终遵循了 Warrenm 1 的建议选项 - 将 .metal 文件转换为字符串并调用 newLibraryWithSource:options:error:.虽然它的性能不是最好的，但它允许我只发布一个框架文件，而无需导入额外的资源.这对于创建使用 Metal、ARKit 等和着色器文件的框架的人来说可能很有用.

Update: For those who tackle this - I ended up following warrenm's 1's suggested option - converted the .metal file into a string and calling newLibraryWithSource:options:error:. Although it is not the best in performance it allowed me to ship only one framework file, without additional resources to import. That could be useful to whoever creating framework that uses Metal, ARKit, etc with shader files.

推荐答案

有很多方法可以为 Metal 着色器提供静态库，所有这些方法都有不同的权衡.我会在这里一一列举.

There are many ways to provide Metal shaders with a static library, all with different tradeoffs. I'll try to enumerate them here.

1) 将您的 .metal 文件转换为静态字符串，这些字符串被烘焙到您的静态库中.

1) Transform your .metal files into static strings that are baked into your static library.

这可能是最糟糕的选择.这个想法是您将 Metal 着色器代码预处理为字符串，这些字符串作为字符串文字包含在您的静态库中.然后，您将使用 newLibraryWithSource:options:error: API(或其异步兄弟)将源转换为 MTLLibrary 并检索函数.这需要您设计一个过程来进行 .metal 到字符串的转换，并且您失去了着色器预编译的好处，使生成的应用程序变慢.

This is probably the worst option. The idea is that you preprocess your Metal shader code into strings which are included as string literals in your static library. You would then use the newLibraryWithSource:options:error: API (or its asynchronous sibling) to turn the source into an MTLLibrary and retrieve the functions. This requires you to devise a process for doing the .metal-to-string conversion, and you lose the benefit of shader pre-compilation, making the resulting application slower.

2) 将 .metal 文件与您的静态库一起发送，并要求库用户将它们添加到他们的应用目标中

2) Ship .metal files alongside your static library and require library users to add them to their app target

考虑到所有因素，这是一个不错的选择，尽管它会给您的用户带来更多负担并暴露您的 Metal 着色器源(如果这是一个问题).静态库中的代码可以使用默认库"(newDefaultLibrary)，因为代码将被 Xcode 自动编译到应用程序的 default.metallib 中，该代码嵌入在应用程序包作为资源.

All things considered, this is a decent option, though it places more of a burden on your users and exposes your Metal shader source (if that's a concern). Code in your static library can use the "default library" (newDefaultLibrary), since the code will be compiled automatically by Xcode into the app's default.metallib, which is embedded in the app bundle as a resource.

3) 随静态库一起发送 .metallib 文件

3) Ship a .metallib file alongside your static library

这是易用性、性能和安全性之间的一个很好的中间地带(因为它不会暴露你的着色器源，只暴露它的 IR).基本上，您可以在项目中创建一个Metal Library"目标，将着色器代码放入其中.这将生成一个 .metallib 文件，您可以将它与您的静态库一起提供，并将您的用户作为资源嵌入到他们的应用程序目标中.您的静态库可以在运行时使用 newLibraryWithData:error: 或 newLibraryWithURL:error: API 加载 .metallib.由于您的着色器将被预编译，因此创建库的速度会更快，并且您将保持编译时诊断的优势.

This is a good middle ground between ease-of-use, performance, and security (since it doesn't expose your shader source, only its IR). Basically, you can create a "Metal Library" target in your project, into which you put your shader code. This will produce a .metallib file, which you can ship along with your static library and have your user embed as a resource in their app target. Your static library can load the .metallib at runtime with the newLibraryWithData:error: or newLibraryWithURL:error: API. Since your shaders will be pre-compiled, creating libraries will be faster, and you'll keep the benefit of compile-time diagnostics.

这篇关于作为 iOS 框架一部分的 Metal 文件的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！