Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
Mono organizations on
GitHub to continue tracking issues. Bugzilla will remain
available for reference in read-only mode. We will continue to work
on open Bugzilla bugs, copy them to the new locations
as needed for follow-up, and add the new items under Related
Our sincere thanks to everyone who has contributed on this bug
tracker over the years. Thanks also for your understanding as we
make these adjustments and improvements for the future.
Please create a new report for Bug 22378 on
Developer Community or GitHub if you have new
information to add and do not yet see a matching new report.
If the latest results still closely match this report, you can use the
In special cases on GitHub you might also want the comments:
GitHub Markdown with public comments
IMTLLibrary defaultLibrary = device.CreateDefaultLibrary ();
In Obj C: defaultLibrary contains an MTLDebugLibrary object.
In C# I get a null object.
This method should load all the shader files with a metal file extension in the project.
Version 5.4 (build 144)
Installation UUID: 145b5200-de94-4a06-b034-848d653982c3
Mono 3.8.0 ((no/62a857e)
GTK+ 2.24.23 (Raleigh theme)
Package version: 308000007
Apple Developer Tools
Xcode 6.0 (6256.16)
Version: 18.104.22.168 (Business Edition)
Build date: 2014-08-25 14:53:28-0400
Version: 4.17.0 (Business Edition)
Android SDK: /Users/Vince/Library/Developer/Xamarin/android-sdk-macosx
Supported Android versions:
2.1 (API level 7)
2.2 (API level 8)
2.3 (API level 10)
3.1 (API level 12)
4.0.3 (API level 15)
4.4 (API level 19)
Java SDK: /usr
java version "1.8.0_20-ea"
Java(TM) SE Runtime Environment (build 1.8.0_20-ea-b23)
Java HotSpot(TM) 64-Bit Server VM (build 25.20-b22, mixed mode)
Version: 22.214.171.124 (Business Edition)
Release ID: 504000144
Git revision: a4978c940debff8b25071bccb08d9eb97eede991
Build date: 2014-08-25 17:16:19-04
Xamarin addins: fe578a7d14c5deb742f4a6e59932e3d6dfcaa678
Mac OS X 10.10.0
Darwin iMac.local 14.0.0 Darwin Kernel Version 14.0.0
Sat Aug 9 00:14:02 PDT 2014
At a minimum (if not attaching a self-contained test case) please give us a code block that compile.
> IMTLLibrary defaultLibrary = device.CreateDefaultLibrary ();
The above does not and I have not used metal before (and, as much as I like to learn it, there's not much change this will happen tonight between two other bug fixes and builds).
p.s. don't assign bugs, my query covers all open bugs and most people (including myself) won't look at assigned bugs (because we mostly self-assign them to avoid duplicating work).
I'm sorry I didn't that because nobody asked me before, here is a little project that uses Metal and build. The previous line is in the project and if you debug it you can the that the object is null, and it shouldn't.
Just moving this one back to NEW for now. If Sebastien has time to look at this and needs more info, he'll put it back to NEEDINFO.
Hey @Vincent is this sample based on a ObjC one? if so could you share it with me too?
It's the Xcode metal template. You can create one as a new project.
It seems that our default.metallib is 6kb and the one generated with Xcode is 11kb
There is a workaround :
Use CreateLibrary (path, options, error) instead where path is a string literal with the content of the metal file.
While Apple did change an argument in the cmd tools comment #6 is not the actual problem.
The issue here is that
defaultLibrary = device.CreateDefaultLibrary ();
Assumes that "/" is our current working directory (wrong assumption by Apple already filled a bug) so adding
Environment.CurrentDirectory = "/";
before any of the Metal calls will make CreateDefaultLibrary() succeed.
@Sebastien @Rolf I don't know what implications this has since we expect that current working directory is the root of the sandbox IIRC. So:
Is it safe to set "/" as our current working directory? i.e. No issues with Assembly Loading, Runtime Assumptions etc.
Should we mimic what Xcode does? i.e. set "/" as cwd by default.
@Vincent @Oleg Please until more light is shed here please stick to your workaround ;)
The app can change the current working directory at will, and it won't affect assembly loading / runtime assumptions on our part.
That said I'm not sure we can change the current working directory for all apps, because many existing apps probably depend on the current behavior.
Question is: how to we make any default app work ? (like Xcode)
i.e. It's not obvious you have to set the CWD to /
Do we know if `CreateDefaultLibrary` the only API that requires this ?
Side note: maybe we should be chaning the CWD for unified to match ObjC apps. It's not the first time (3rd party code) that this cause an issue.
> Question is: how to we make any default app work ? (like Xcode)
This for at least Metal apps will be frustrating since like you said it is not an obvious change. We can either document it very well and wait for Apple to hopefully fix it or just make the change on Unified.
> Do we know if `CreateDefaultLibrary` the only API that requires this ?
This is more a question for @Vincent and @Oleg since they have been working with the api.
> Side note: maybe we should be chaning the CWD for unified to match ObjC apps.
It's not the first time (3rd party code) that this cause an issue.
+1 on changing CWD to "/" be the new default, this is what Apple does (and sometimes expects) if we really want to match Xcode's behaviour this is the right time to do it for unified. For Classic this is a little late but we can make sure to document this change on unified.
I'm fine with changing CWD for unified projects to match ObjC apps (I don't know why we're changing CWD in the first place anyway, the original commit  doesn't explain much).
Now XS compiles all metal files into default.metallib file and the name of the metallib file always stays the same. Also IMTLDevice.CreateLibrary ("default.metallib", out err) returns usable library. Probably it's good idea to call IMTLDevice.CreateLibrary ("default.metallib", out err) inside of IMTLDevice.CreateDefaultLibrary as temporary solution?
Changing the milestone to "C7".
Fixing this requires a runtime breaking change that would affect several applications. We might fix this at some point but definitively not for C7.