Bug 22378 - [Metal] - CreateDefaultLibrary () don't load anything (Has Workaround)
Summary: [Metal] - CreateDefaultLibrary () don't load anything (Has Workaround)
Status: CONFIRMED
Alias: None
Product: iOS
Classification: Xamarin
Component: General (show other bugs)
Version: master
Hardware: All All
: Normal normal
Target Milestone: Future Cycle (TBD)
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2014-08-26 16:34 UTC by Vincent Dondain [MSFT]
Modified: 2016-01-18 13:04 UTC (History)
7 users (show)

See Also:
Tags:
Is this bug a regression?: ---
Last known good build:


Attachments

Description Vincent Dondain [MSFT] 2014-08-26 16:34:50 UTC
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.

==============

Xamarin Studio
Version 5.4 (build 144)
Installation UUID: 145b5200-de94-4a06-b034-848d653982c3
Runtime:
	Mono 3.8.0 ((no/62a857e)
	GTK+ 2.24.23 (Raleigh theme)

	Package version: 308000007

Apple Developer Tools
Xcode 6.0 (6256.16)
Build 6A280e

Xamarin.iOS
Version: 7.99.4.50 (Business Edition)
Hash: 4cb10b2
Branch: 
Build date: 2014-08-25 14:53:28-0400

Xamarin.Android
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)

Xamarin.Mac
Version: 1.10.0.10 (Business Edition)

Build Information
Release ID: 504000144
Git revision: a4978c940debff8b25071bccb08d9eb97eede991
Build date: 2014-08-25 17:16:19-04
Xamarin addins: fe578a7d14c5deb742f4a6e59932e3d6dfcaa678

Operating System
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
    root:xnu-2782.1.80~2/RELEASE_X86_64 x86_64
Comment 1 Sebastien Pouliot 2014-08-26 22:25:23 UTC
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).
Comment 2 Vincent Dondain [MSFT] 2014-08-27 10:05:38 UTC
Hey, understood.

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.

https://drive.google.com/file/d/0B6c9X4nRMiBCUExQcnRDaVVCX1k/edit?usp=sharing
Comment 3 PJ 2014-08-28 17:46:07 UTC
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.
Comment 4 Alex Soto [MSFT] 2014-09-03 13:54:52 UTC
Hey @Vincent is this sample based on a ObjC one? if so could you share it with me too?
Comment 5 Vincent Dondain [MSFT] 2014-09-03 14:19:35 UTC
It's the Xcode metal template. You can create one as a new project.
Comment 6 Alex Soto [MSFT] 2014-09-03 16:34:49 UTC
It seems that our default.metallib is 6kb and the one generated with Xcode is 11kb 

https://hipchat.xamarin.com/files/1/80/01sWnEF830euA5X/upload.png
Comment 7 Vincent Dondain [MSFT] 2014-09-04 13:26:56 UTC
There is a workaround : 

Use CreateLibrary (path, options, error) instead where path is a string literal with the content of the metal file.
Comment 8 Alex Soto [MSFT] 2014-09-05 00:29:33 UTC
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 ;)

Cheers.

Alex
Comment 9 Rolf Bjarne Kvinge [MSFT] 2014-09-05 07:39:07 UTC
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.
Comment 10 Sebastien Pouliot 2014-09-05 10:37:46 UTC
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.

Thoughts ?
Comment 11 Alex Soto [MSFT] 2014-09-05 10:57:39 UTC
> 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.

my $0.02.
Comment 12 Rolf Bjarne Kvinge [MSFT] 2014-09-05 11:00:17 UTC
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 [1] doesn't explain much).

[1] https://github.com/xamarin/maccore/commit/95b634e4a2a76e2842030c0810bb82ac898a71b8
Comment 13 Oleg Demchenko 2014-09-08 13:20:49 UTC
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?
Comment 14 GouriKumari 2016-01-12 22:33:29 UTC
Changing the milestone to "C7".
Comment 15 Sebastien Pouliot 2016-01-18 13:04:04 UTC
Fixing this requires a runtime breaking change that would affect several applications. We might fix this at some point but definitively not for C7.

Note You need to log in before you can comment on or make changes to this bug.