[Bill Hollings]

@saahiljeet

That info message is reported in any one of three situations:

• You are not compiling for 64-bit architecture. If building for 32-bit architecture, you can bypass this check by setting the MLN_ARCH_SUPPORTS_METAL compiler build setting to YES (or 1).
• Your build environment sets either the MLN_ARCH_SUPPORTS_METAL or MGL_SUPPORT_OPENGL_ON_METAL compiler build setting to NO (or 0). Normally you would not set these directly.
• The MTLCreateSystemDefaultDevice() function does not exist or does not return a MTLDevice instance, which would happen if Metal is not available on the device (minimum iOS 8 on an A7 processor).

Do any of those apply?

…Bill

[Bill Hollings]

I have added a request to the GLFW community to add support for Vulkan on macOS and iOS through MoltenVK.

Please add your voice there if you would like to see this happen.

…Bill

[Bill Hollings]

@soso7885

MoltenVK is a driver for Vulkan on macOS and iOS. It will work with any Vulkan development kit or engine that links to it. However, it is up to the development kit or engine to use the extension required to support any given platform (e.g.- Windows, macOS, etc).

GLFW is open-source. We recommend that you post a request to the GLFW development community to support macOS on Vulkan by making use of a library such as MoltenVK. We will do the same, and we’ll see if we can get the ball rolling.

…Bill

[Bill Hollings]

@soso7885

Yes, we definitely plan to support Vulkan validations layers. We are working with LunarG to add macOS and iOS support to their validation layers.

Unfortunately, I cannot give you a timeframe for their availability yet.

…Bill

[Bill Hollings]

@liutenantcoconut

glGenerateMipmap(GL_TEXTURE_2D); works consistently in other situations.

Hmmm…I’m wondering if you are attempting to generate a mipmap when a texture is not actually bound to GL_TEXTURE_2D…and the existing driver is safely ignoring the unbound texture.

…Bill

[Bill Hollings]

@liutenantcoconut

The glGenerateMipmap() function is supported by MoltenGL.

What makes you think mipmaps are not supported? Can you provide a bit more information, such as a stack trace? What device and OS version you are running this on?

…Bill

[Bill Hollings]

@LiutenantCoconut

Are you using the GLKView implementation from the MoltenGL package?

Please read the EAGL and GLKit System Classes section of README_MoltenGL_UserGuide.md for more info about use of GLKit components.

…Bill

[Bill Hollings]

@bsder

MoltenVK itself operates as a driver (ie- layer 0).

Vulkan validation layers are not yet available for the iOS and macOS platforms.

…Bill

[Bill Hollings]

@bsder

CAMetalLayer is part of the QuartzCore system framework…so you need to link in that framework as well.

Unfortunately, the README_MoltenVK_UserGuide.md document does not mention that, which is a documentation oversight.

…Bill

[Bill Hollings]

If not using Xcode, what tool will you compile your app (and MoltenVK) with?

If you are using Make, etc, you should still be able to use the MoltenVK framework. You can also use the static library within the MoltenVK framework directly.

…Bill

[Bill Hollings]

@edsel.malasig

What part confuses you? Do you have a particular question that we could answer to help clarify things?

The README_MoltenVK_UserGuide.md document in the Molten download package discusses the automatic conversion of SPIR-V shaders to MSL shaders in significant detail.

…Bill

[Bill Hollings]

@pixel-music

Starting with a clean Molten 0.13.0 download, and following the instructions, we are not able to replicate this here with either Xcode 7.3.1 (7D1014) or Xcode 8.0 beta 6 (8S201h).

It should not matter, but what version of Xcode are you using? And did you change the Xcode project in any way prior to attempting to build the demo?

…Bill

[Bill Hollings]

That is an interesting option…and might make sense for educational or other non-profit use.

We will review that internally.

…Bill

[Bill Hollings]

@geenz

Can you be more specific about what you are proposing? What type of open-source projects are you looking to support, and under what conditions?

For example, are you thinking of a situation where final products (eg- app or game, etc.), would also be free (ie- no one is making money), such as in say an educational or hobby market?

…Bill

[Bill Hollings]

@Micha

The MoltenGL library is only built for 64-bit applications, because that is a requirement for Metal. So the MoltenGL library will not be linkable to your application in 32-bit mode.

Can you provide some more background as to why you want to compile in 32-bit mode?

…Bill

[Bill Hollings]

@abaa

There are, of course, many factors that go into the performance of a game on any platform, so a blanket estimate of the variation between a game running on MoltenVK on macOS, vs the same game on Windows 10, using another Vulkan driver, is not something I can answer.

Your best bet is to determine the characteristics of your game, and build one or more test cases to explore those requirements in more detail, before porting the entire game.

MoltenVK is quite new, and depending on your requirements, you should also review the list of known limitations for the current release, which you can find in the README_MoltenVK_UserGuide.md document in the Molten download.

…Bill

[Bill Hollings]

@abaa

I’m not sure what you are asking. What do you mean by “native OS”?

What are you trying to compare the performance of MoltenVK on macOS against?

…Bill

[Bill Hollings]

@Pierre

Be sure to read the EAGL and GLKit System Classes section of the README-UserGuide.md document found in the MoltenGL distribution package. This will explain how to use the standard GLKViewController and a Storyboard to instantiate your custom MGLGLKView subclass.

You can also refer to the DemoViewController class and Main.storyboard within the DrawLoadDemo for an example of using this technique.

The key is to create a custom MGLGLKView subclass, and identify it in the Storyboard. You can use the standard GLKViewController framework class (or your own subclass) to control it.

…Bill

[Bill Hollings]

I’m not clear what you mean by “convert Vulkan code to Metal code”, but I’ll take a stab at answering.

MoltenVK is a Vulkan implementation, and you use the standard Vulkan API in your application or game. You do not need to use any Metal functionality. For example, you can take an application or game written for Vulkan on another platform and run it unchanged on iOS and OS X using MoltenVK as the Vulkan implementation. MoltenVK uses Metal under the covers.

This portability includes the shaders. Vulkan uses SPIR-V shaders, and MoltenVK accepts them, and converts them automatically to the Metal Shading Language for use on iOS and OS X. You do not need to convert your shaders from one platform to the other.

I hope this answers your question. If not, please clarify the specifics you are looking for.

…Bill

[Bill Hollings]

@yincg

You are not providing enough information for us to help you. There are many reasons why the application may be running slower, including those answered in your other post. Are you able to post your app somewhere, as requested in the previous post?

In the numbers you do provide above, MetalGL‘s CPU performance is substantially better than OpenGLES, as it should be. MetalGL is designed to improve CPU performance, as discussed in the README-UserGuide document.

From your numbers above, your performance bottleneck appears to be in the shaders. It is possible that the automatic conversion of one or more of your shaders has resulted in inefficient Metal Shading Language (MSL) code. You can tune the shaders once they have been converted to MSL and load them directly as MSL code. An explanation of how to do this is in the README-UserGuide document as well.

…Bill

[Bill Hollings]

@yingcg

It’s hard to determine what’s going on with the amount of information you are providing.

Are you running in Release mode? Metal’s Debug mode is very slow.

If you are still having trouble, ZIP up your Xcode project, upload it to Dropbox (or similar site), post a link to it here, or email the link to support@moltengl.com, and we’ll download your app and have a look at it.

…Bill

[Bill Hollings]

@yincg

MetalGL should certainly not be running slower than native OpenGL ES 2.

Be sure you have read the Performance Considerations section of the README-UserGuide document. In particular, be sure you have configured your Xcode Scheme correctly, as explained there.

…Bill

[Bill Hollings]

@yincg

Sorry for the delay in getting back to you. We have been very busy this week with activities associated with the Vulkan public release this week.

If you look at the inclusion order of the error (in the attached image), you can see that the system header chain eventually tries to include a file called block.h. Unfortunately, your project also contains a file with that name, and it attempts to then include further header files in your project, eventually looking for cmath.

As I mentioned above, the compiler does not find cmath, because it is not looking for C++ files, since the source file it is attempting to compile at the time (see the top of the list in the error) is test_project.m, which is an Objective-C file.

You have a couple of options. The simplest is to change the name of test_project.m to test_project.mm, so that it will be compiled as Objective-C++ and will find the cmath system file. This is a sensible thing to do anyway, since your project includes a substantial third-party C++ library, and any Objective-C files that use it will need to be (.mm) files.

The second option (for more complicated projects) is to compile the third-party library in a separate build target within your project, and leave the ALWAYS_SEARCH_USER_PATHS turned off on that project target. You only need to set the ALWAYS_SEARCH_USER_PATHS option for code that needs to include the gl.h or glext.h files when using MetalGL.

…Bill

Screen-Shot-2016-02-17-at-11.03.09-PM

[Bill Hollings]

@yincg

cmath is usually used in C++ libraries. Xcode will usually only search for cmath as a system header when it is referenced from a C++ source file. The error you are getting typically arises when a header file included by a non-C++ source file (C, Objective-C or Swift file) indirectly includes cmath.

The cmath header is not used by MetalGL. I suspect that you have a header file somewhere in your User Header Search Paths that overrides (has the same name) as a system header file, and that header file is including cmath.

Check your User Header Search Paths Xcode build setting, the header files included from that path, and the header files included in your Xcode project, to see if that is the case. Within Xcode, you could also search for references to cmath.

If you continue to have trouble, ZIP up your Xcode project, upload it to somewhere like Dropbox, post a link to it here, and we’ll have a look at it. If you don’t want to post the link here, you can email the link to support@metalgl.com directly.

…Bill

[Bill Hollings]

@den_ct

We assess project priorities based on demand.

Given current project priorities, support for OpenGL ES 3 is not expected until late in 2016.

Support for OpenGL ES 2 on OS X is already available in the current release of MetalGL.

…Bill

[Author]

Posts