I'm very pleased to present full bindings to the MetalPerformanceShadersGraph framework!
I'm happy with how everything turned out with the exception of a few notes and questions below.
I re-implemented Apple's MNIST sample (from https://developer.apple.com/documentation/metalperformanceshadersgraph/training_a_neural_network_using_mps_graph) here:
https://gist.github.com/praeclarum/b8077771fb341a1f9c28240113e00425
It's also added as a unit test.
Fixes#14286
### Notes
* Although the API says it works on macOS 11, it has bugs and crashes with errors even with Apple’s Swift examples. It’s better on macOS 12. iOS 14 and on is fine.
* `MPSGraphSparseStorageType` has terrible names. They match Apple's but I wish they were better.
* I added convenience methods to `MPSNDArray` and `MPSGrapTensorData` and the `Variable` and `Constant` operations to decrease the amount of unsafe code users have to write. I currently do this for 32-bit floats, the most common data type.
Co-authored-by: Alex Soto <alex@alexsoto.me>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
Adjust our versioning scheme so that the NuGet version is
`Major.Minor.CommitDistance`. The previous scheme ("Major.Minor.<fixed-ish
version>") causes problems on branches producing stable builds, because each
new commit would end up with the same NuGet version, and we wouldn't be able
to push those to a NuGet feed because there might already be an existing
version there.
By using the commit distance in the NuGet version we ensure that every commit
has a different version.
We already have a few attributes that can specify the native name for a type, whenever the native name doesn't match the managed name:
* [Register ("DifferentClassName"): specifies the Objective-C class name
* [Native ("DifferentEnumName")]: specifies the Objective-C enum name (and also that it's a native-sized enum)
* [Protocol ("DifferentProtocolName")]: specifies the Objective-C protocol name
* [Category ("DifferentCategoryName")]: specifies the Objective-C category name
Unfortunately this leaves (at least) two cracks:
* Objective-C structs.
* Objective-C enums which aren't native-sized.
So I'm adding a [NativeName] attribute for this purpose, and updating numerous
types to specify the native name (either using an existing [Native] attribute
for enums that already have one, or by adding a new [NativeName] attribute).
The static registrar needs to know the native name for such types, in case
they appear as parameter types in function signatures.
This also allows us to simplify xtro a bit, to not have a separate map of
managed name given a native name, because we can now build that map
dynamically.
Added code to:
compile a string to a platform library
collect the output of the compilation process
check for errors
Added a single unit test of the smoke test variety.
We need to be able to embed the dlls as a resource to compare the diff
assemblies. To do so we are going to ensure that we have called make in
the root dir so that the needed deps are present. This change is not yet
in the csproj, that will be a diff commit.
Co-authored-by: Chris Hamons <chris.hamons@xamarin.com>
- .NET5 on my mac has inconsistent debugging due to lack of support for apple's arm arch
- The tool is going to run against NET6, so why built it on NET5
* Update dependencies from https://github.com/dotnet/runtime build 20220503.10
Microsoft.NETCore.App.Ref
From Version 6.0.5 -> To Version 6.0.6
* Update dependencies from https://github.com/dotnet/runtime build 20220504.4
Microsoft.NETCore.App.Ref
From Version 6.0.5 -> To Version 6.0.6
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.301-rtm.22253.26 -> To Version 6.0.301-rtm.22254.17
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
* add nullable enable
* throw better null exception
* use is null
* Forgot an is null
* use GetHandle
Co-authored-by: tj_devel709 <antlambe@microsoft.com>
There's no AOT compiler for macOS, so setting _RunAotCompiler causes problems
because if it's set, we try to find the AOT compiler, and because there is
none, the build fails.
So don't set '_RunAotCompiler' if 'MtouchInterpreter' is set (which also
indirectly means if 'UseInterpreter' is set) to avoid the problem altogether.
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.300-rtm.22220.25 -> To Version 6.0.301-rtm.22253.26
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>