金属文件作为iOS框架的一部分 [英] 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).基本上，您可以在项目中创建一个金属库"目标，将着色器代码放入其中.这将生成一个.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框架的一部分的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！