Can you please try with --target=air64-apple-xros1.0?
You do not need to explicitly set any MTLCompileOption to get -O2 optimization level as that is the default. The explicit level in the API is MTLLibraryOptimizationLevelDefault.
While man metal mentions all those options, please note that in the Metal Shading Language Specification 3.1 §1.5.5 (Optimization Compiler Options) lists -O2 and -Os (just like the documentation for MTLLibraryOptimizationLevel) as the only supported options.
You'll need to qualify the this pointer using the following syntax:
float operator[](int i) device const {
return data[i];
}
You'll need to do this for any address space you expect to use your struct for.
Post not yet marked as solved
You could do something like this:
struct Uniforms {
float ratio1;
int opr1, opr2;
};
int peIndex [[ thread_position_in_grid ]]; // New in MSL 3.1
[[ kernel ]]
void testFunction(constant Uniforms &uniforms, // implicitly [[ buffer(0) ]]
constant float *input1, // implicitly [[ buffer(1) ]]
constant float *input2, // implicitly [[ buffer(2) ]]
device float* outputs // implicitly [[ buffer(3) ]]
) {
// main compute block
}
You should look at setBytes:length:atIndex: and setBuffer:offset:atIndex: APIs for the host side.
While it's not compute, there's the Using a Render Pipeline to Render Primitives that uses setVertexBytes whose usage is quite similar to the compute equivalent.
There is no difference between thread_execution_width and threads_per_simdgroup. We've noted in Metal Shading Language 3.0 that:
thread_execution_width
All OS: Since Metal 1.0.
[[ Deprecated as of Metal 3.0 – use threads_per_simdgroup ]]
There's also this line:
[[threads_per_simdgroup]] and [[thread_execution_width]] are aliases of one another that reference the same concept.
Yes, you do need to specify the -target option like this: -target air64-apple-ios16.0.
The full syntax for specifying the target triple can be found at https://clang.llvm.org/docs/CrossCompilation.html but for our purposes you can break it down as <arch>-<vendor>-<minimum deployment target>. air64 must be the architecture and apple must be the vendor. The OS that we support are: ios, tvos (with the iOS toolchain in the ios subfolder) and macos (with the macOS toolchain in the macos subfolder).
Besides that you can also specify an environment in your triple with a suffix to the last part of the triple. The two environments that are supported are the Simulator (for which the suffix is -simulator) and MacCatalyst (for which the suffix is -macabi). For the simulator you'll need to use the iOS toolchain and for MacCatalyst you should use the MacOS toolchain (and specify the iOS deployment target.
Here are some examples of triples you can use with the -target option with the iOS toolchain:
-target air64-apple-ios16.0
-target air64-apple-tvos16.0
-target air64-apple-ios16.0-simulator
-target air64-apple-tvos16.0-simulator
Here are some examples of triples you can use with the -target option with the macOS toolchain:
-target air64-apple-macos13.0
-target air64-apple-ios16.0-macabi
Post not yet marked as solved
Hey Alecazam, thanks for surfacing this. We are aware of this limitation and are tracking it. If you would like updates on the progress of this - please file an feedback request.
Post not yet marked as solved
There isn't a way to do that today. Can you please file a FBA for this enhancement?
Post not yet marked as solved
The fact that frameworkBundle is returned as nil is the main problem here.
For (A):
The documentation for Bundle has:
// Get the bundle containing the specified private class.
let myBundle = Bundle(for: NSClassFromString("MyPrivateClass")!)
so could you please try:
let frameworkBundle = Bundle(for: self.Type)
Post not yet marked as solved
Thanks for reporting this issue. Can you please share the feedback assistant ID that you created for this?
Basically, if the data will need to be read by the CPU later, do it on the CPU. If it's just for display and the data was on the GPU anyway, do it on the GPU.
For this small a data-set, is unlikely that you will be able to measure the performance difference by trying to simplify the transformations. You are more likely to see speedups by trying to reduce the number of draw calls by batching.
For general guidance on GPU programming, you might want to watch Advanced Metal Shader Optimization - https://developer.apple.com/videos/play/wwdc2016/606/.
Please specify an iOS or tvOS deployment target when using the tools from the iOS directory. Similarly, use a macOS deployment target when using tools from the macOS directory.
For example the following would work:
MetalDeveloperTools\ios\bin\metal -target air64-apple-ios14.0 -c test.metal -o test.air
MetalDeveloperTools\ios\bin\metallib test.air -o test.metallib	
We recommend using the metal as a driver to do your linking as well as:
MetalDeveloperTools\ios\bin\metal -target air64-apple-ios14.0 test.air -o test.metallib	
Or you could do all this in a single line as:
MetalDeveloperTools\ios\bin\metal -target air64-apple-ios14.0 test.metal -o test.metallib	
You should not mix targets and tools in your workflow.
Post not yet marked as solved
Generally speaking you should be able to download release version of the tools from the release tab - https://developer.apple.com/download/release/ under Applications.
If we have a a beta version available, it can be downloaded from the beta tab. - https://developer.apple.com/download/ also under Applications.
You may also download the tools using the more tab - https://developer.apple.com/download/more/?=Metal%20Developer%20Tools%20for%20Windows.
Thanks for bringing this to our attention. We will be updating the docs soon.
We have added support for uint64_t buffers in v2.3 of the Metal Shading Language.
Please note that 64-bit integers are only supported on MTLGPUFamily.apple3 and above.
On other GPU families 64-bit integers aren't fully supported yet.
