It has been a while since I have used XCode, but since Apple revieled XCode 6 and the new Metal API I had to check it out.
They have released examples, e.g. a converted version of their Basic3D example. I am having problems making them compile and run, though. I had to add paths the Quatz and Metal frameworks for compilation and linking to work - thought that should have worked out of the box with build-in libraries?
Also the metal shader compilation step fails, it can not find the metal compiler. Where in XCode is that path setup?
If I ignore the shader compilation step I get an error that the application will not run on any of the simulators. Can metal based 3D applications only run on actual hardware and not in simulator mode?
According to a staff on Apple dev forums, Metal does not run in the simulator.
See: https://devforums.apple.com/message/971605#971605
If you look at other samples/app templates there is no need to explicitly link any framework, indeed everything runs out of the box.
You can't run metal on simulator but you can use this workaround so that it will still compile as long as you have a fallback for the code.
http://medium.com/#jscampbell/bare-metal-working-with-metal-and-the-simulator-70e085e3a45
I started with the hello triangle example they give you to download. It contains all the platform #if's you need to know about. I recommend you get that project and take a look.
https://developer.apple.com/documentation/metal/hello_triangle
#if TARGET_OS_SIMULATOR
#error No simulator support for Metal API. Must build for a device
#endif
Related
I have an application written in Swift on SceneKit + Metal. When I build and run the app from Xcode fps counter shows 40fps. But if I run the app myself by tapping the icon on springboard fps counter shows 60fps. How could it be? Could Xcode somehow affect app performance while debugging? I have no idea how this all works, but I suppose there could be some hooks for debugging to work correctly which affect performance. If so, can I opt-in from this?
I'm aware of different build flags for debug and release builds, but I don't make release build. Performance differs in the same debug build while running from Xcode vs when I run the app manually on the phone.
By default, Xcode enables the Metal validation layer. That does a bunch of additional checking of how you're using it to catch incorrect uses. The additional checking is slow, which is why Metal doesn't do it unless validation is enabled.
This can be changed in Xcode's Scheme editor. This is documented in Apple's Metal Programming Guide.
A nice tutorial on iOS Assembly. This might be insightful on the topic
As stated, this is because the compiler is in debug mode, meaning no optimizations are made. If you turn optimizations on, then you’ll see a much smaller function generated.
And also check out this answer about changing optimization levels.
I've experimented with different options in scheme editor and have find out that Debug executable checkbox affected performance in my case. So my assumption about debugger was right, but I didn't know about that checkbox before.
I'm trying to compile a dependent libraries from the source code and I've got this error:
/Applications/Xcode.app/Contents/Developer/Platforms/AppleTVOS.platform/Developer/SDKs/AppleTVOS9.0.sdk/usr/include/unistd.h:446:8:
note: 'fork' has been explicitly marked unavailable here pid_t
fork(void) __WATCHOS_PROHIBITED __TVOS_PROHIBITED;
Is there any way to resolve this issue?
The thing is that I don't actually even need this functionality. When I compile this code for iOS and run it under tvOS then it works.
But I can not submit the application because it contains code compiled for iOS.
What would be the good trick to substitute there a dummy fork() function so it compiles OK (believing that it is not actually used by my specific use-cases).
I don't believe there is a way round this. You cannot create processes under iOS and tvOS is 90% iOS, so the same restriction applies.
You'll have to conditionally compile-out that section of code for iOS/tvOS.
As part of a research project at school, I'm exploring mobile specific energy optimizations and am building infrastructure to test these optimizations on a popular mobile platform. Given my background in LLVM, I have decided to setup the testing infrastructure around the iOS platform. I thought that since Xcode already uses LLVM under the hood, it should be easy to integrate a copy of LLVM compiled from source into the Xcode toolchain, but I haven't been able to find an option to accomplish it in Xcode yet. (I'm new to OSX and haven't worked with Xcode before)
Am I overlooking anything, or is such an integration not supported out of the box in Xcode?
It's for obfuscater-llvm, but it should work for a "normal" llvm:
https://github.com/obfuscator-llvm/obfuscator/wiki/Installation#integration-into-xcode
I downloaded this project to give it a try (http://www.hatzlaha.co.il/150842/Lucas-Kanade-Detection-for-the-iPhone). It also has a released version on AppStore.
When I downloaded the source and compiled, it gave compilation errors. I changed the compiler to LLVM GCC and it instantly compiled without any errors or warnings.
Further here is what I did:
Downloaded the app Lucas Kanade on personal iPhone. Runs as expected (ie. shows tracked points and video output).
Deployed the above compiled app on company iPad. Here is shows the tracked points (which means the application is getting the video frames) but not able to display the video output.
General app flow:
Grab a frame from the camera.
Process the frame (track points).
Output the frame, so the screen looks like its showing the camera feed, as expected.
Device details:
iPhone: OS 5.1.1 (9B206); iPhone 4;
iPad: OS 5.1 (9B176); iPad 2;
Questions
Is the video output problem occurring because of the different in OS versions or because of the GCC compiler being used?
If it is the compiler problem, would be be appropriate to put the compile errors here for resolution or do I need to start a separate Question?
I know this info might not be enough since there are a lot of unknowns, but trust me, getting into the details of the app would be a really exhaustive problem description. Let me know what more info is needed to guess the solution. I'll update it here.
Like you already said the info is not enough. I can just guess. The projects for tracking points uses generally their own driver for camera access. The reason, why it does not work with llvm compiler, might be that.
Just look in the project if you find any file specific to iPhone. They are mostly dat files. And maybe you find some preprocessor macros in the project like #ifdef target_iphone something like that. In that case you can contact the producer and request the driver for iPad.
I did not download and tried the project, but it is just a guess.
I have a code base which compiles fine in all other NEON compilers, ndk-build, RVDS, etc, but under Xcode I get the error "bad instruction" for every NEON instruction I call. It basically seems like NEON is not detected.
I am attempting to build a static library, I went to New Project, selected Cocoa Touch Static Library, then added my existing files.
Everything I'm reading indicates that NEON should be already enabled. I removed all references to armv6, and am targeting iOS 5.1
Also the code in question is all contained as routines defined in ".s" files -- pure assembly. I am not using the intrinsics method calls.
It seems like the compiler is barfing on the whole file...
Unknown pseudo-op: .cpu
It lists all of the other settings, like .fpu, etc
Here are my current settings:
(source: wasteonline.net)
(source: wasteonline.net)
(source: wasteonline.net)
After the as tool I mentioned in my last answer turned out to be choking on my syntax as well, I realized there must be something else going on.
I followed the guidelines on the bottom of this post http://www.shervinemami.info/armAssembly.html#template
The changes I needed to make were:
converted my instructions to all lower case
use the naming directives to be compatible with mach-o (solved linker problems)
Try to use GCC4.2. I solved a very similar problem switching to the old, good GCC.
In Build Settings -> Compiler for C/C++/Objective-C, select GCC
Actually, if you check the LLVM ARM status page, you'll see that it cannot yet parse .S files.