[Bill Hollings]

odin@j2jlab.com

MetalGL will automatically run native OpenGL ES when running on a 32-bit arm7 device like the iPhone 4S.

You don’t need to do anything to enable this, but make sure that you are not forcing the value of the MGL_SUPPORT_OPENGL_ON_METAL build setting.

For more info, you can review the Device Platforms and OpenGL System Classes section of the README-UserGuide.md document.

…Bill

[Bill Hollings]

@Thufir

Yes, as with OpenGL ES, MetalGL supports interleaved vertices.

…Bill

[Bill Hollings]

@Thufir

What do you mean by “requirements for vertex format”?

…Bill

[Bill Hollings]

@Thufir

Make sure all of the app code has access to the MetalGL headers, and that you are not using pre-compiled code that can’t see the headers, like GLKit or SpriteKit components.

You can use GLKView, but follow the instructions in the *EAGL and GLKit System Classes* section of the README-UserGuide.md document.

…Bill

[Bill Hollings]

@DEN_CT

Support for OpenGL ES 3.0 is a priority, but at this point we can’t provide a release date.

…Bill

[Bill Hollings]

@jamesfolk1

The iPhone 5 is not compatible with Metal, because it has a 32-bit ARM processor. Metal requires a 64-bit A7 processor or better. As far as iPhones go, that means an iPhone 5S or later model.

Have a look at the README-UserGuide.md document in the MetalGL package. The requirements are explained there.

Having said that, the MetalGL demos should run on an iPhone 5, but when they do, they will use the native OpenGL ES engine. We’ll look into why the demo doesn’t work correctly in that situation.

…Bill

[Bill Hollings]

@jamesfolk1

MetalGL cannot be run with the Xcode simulator, because the Xcode simulator does not support Metal.

For the iOS build, what iOS device and iOS version are you trying to run the demos on?

…Bill

[Bill Hollings]

@starbird1975

1. MetalGL will always have a shader converter component and stand-alone tool. However, we will be introducing a different converter (and tool) in the future, in order to handle situations that the current converter cannot handle.

2. The current shader converter in MetalGL is actually a thin wrapper around an existing open-source library. As such, you are not required to pay a license fee for use of the MetalGL shader converter as a stand-alone tool. And of course, you are free to use the open-source library by itself, or the MetalGL mods to the open-source converter, which are also open-source. This licensing stance may change when we introduce the more comprehensive converter (ie- a “pro” converter version, per se).

…Bill

[Bill Hollings]

@anchor

Strange. There is no difference between 2D and 3D components in OpenGL (or MetalGL). Are the 2D components being rendered by Horde as well, or are they being rendered from a different library that might not be compiled with MetalGL?

You can try capturing a GPU frame to track down what’s happening with the 2D draw calls in Metal. That Apple doc describes capturing an OpenGL ES frame, but when running on Metal, it will capture a Metal frame.

Capturing a GPU frame requires you to be in Debug mode, and have enabled frame capture in the Options pane of the Xcode Scheme Editor:

…Bill

[Bill Hollings]

@anchor

Yes, MetalGL in 32-bit mode currently bypasses Metal, so that 32-bit-only devices don’t try to use it. So, when running in 32-bit mode, you are running native OpenGL ES. We could look into supporting 32-bit mode, but since Apple actively discourages using 32–bit mode on 64-bit devices, it’s not a critical long-term strategy.

Based on your crash log, it looks like you are using GLKit. How much of GLKit are you using? The only part of GLKit that MetalGL supports is GLKView. If you are using GLKView, the README-UserGuide.md document explains how to use it with MetalGL. Specifically, if you have an Storyboard that uses GLKView, you need to establish and use an empty GLKView subclass, so that the Storyboard loader won’t try to load the default system GLKView class (and thereby bypass the MetalGL overrides).

If 2bpp PVRTC textures are critical, we can look to add support for them sooner rather than later.

…Bill

[Bill Hollings]

@anchor

The glTexParameter() call is likely failing because texture ID = 0 is bound to the GL engine when you make that call. OpenGL ES forbids modifying the default texture in any way, but if your app is getting away with it elsewhere, it might be ignored by the native OpenGL ES driver.

Is the first logging above coming from a Release build? And is the glTexParameter() actually causing the crash due to an assertion? It should not be performing assertions in a Release build unless you have added the DEBUG build setting, or unless you have enabled either the GL_ERROR_ASSERTION_MGL or GL_DEBUG_MODE_MGL MetalGL capabilities (using glEnable()).

The 32-bit build you mention is likely coming from the build settings in your app project. Can you double-check them?

When you use Horde3D, are you compiling the Horde3D library with MetalGL as well, or just your app code? It is important that all code that issues OpenGL ES calls be compiled against MetalGL, including any library code.

…Bill

[Bill Hollings]

@starbird1975

Thanks very much for taking the time to provide your feedback. It’s very useful, and much appreciated.

1. At present, only 4bpp versions of PVRTC compressions is supported, due to the need to auto-invert textures between OpenGL ES & Metal texture orientations (the flipping algorithm currently only works for 4bpp compression). We will be moving to a different PVRTC handler in the future, which will correct this.

2. Thanks. You are of course correct. We’ll fix the location = -1 issue in the next release.

…Bill

[Bill Hollings]

@pemgl

You can’t mix Metal and OpenGL in a single app. That means that once you decide to use MetalGL to run your OpenGL ES code in Metal, instead of running the native OpenGL ES engine, you have to ensure that all of your OpenGL ES code is using MetalGL, including any code from any libraries you use. In other words, all of the libraries that use OpenGL ES have to be compiled so they redirect their OpenGL calls to MetalGL.

This might also be a challenge if a library detects what OS it is running on and tries to use desktop OpenGL on OS X instead of OpenGL ES. The way that GL objects like the color renderbuffer are attached to a view is different between OpenGL ES and desktop OpenGL.

For some more background, have a look at the way that the EAGLView and ES2Renderer classes are implemented in Apple’s GLEssentials sample code. You can download this sample and run it with MetalGL under iOS.

The way the EAGLView class creates an OpenGL ES-compatible view is the way that it needs to be done, both on iOS and OS X, because this is the way it’s done with OpenGL ES, and is what MetalGL overrides, both on iOS and OS X. This is also essentially what the MGLGLKView class does, both on iOS and OS X, but through a GLKView API.

In the future, we can explore options for overriding the desktop OpenGL GL context-creation functionality, in order to simplify running an OpenGL ES app on OS X, but for now, it’s important that the GL context and views be constructed the OpenGL ES way, even on OS X.

…Bill

[Bill Hollings]

@pemgl

It looks like you’re using a windowing library that we are not familiar with. Have a look at the DrawLoadDemo to understand how the DemoView class is constructed. It’s based on MGLGLKView, which behaves like Apple’s GLKView class, but handles creating the framebuffers for rendering to Metal.

If you can’t use the MGLGLKView class, can you post the code that creates your NSView, its underlying layer, and how the framebuffer and renderbuffer storage is allocated for that view?

BTW…in future posts, can you surround your code snippets with <pre> code snippet </pre> so that it retains its formatting and is more readable, please?

…Bill

[Bill Hollings]

@pemgl

Yes…installing El Capitan is crucial, since you won’t have Metal available until you do. That’s why you’re seeing the log message you reported:

[mgl-info] OpenGL functionality using Metal cannot be provided because Metal is not supported on this device. OpenGL functionality provided by native OpenGL framework.

Metal is not available on Yosemite, hence the log message.

…Bill

[Bill Hollings]

@pemgl

The egl.h file is indeed missing from RedirectHeaders/include. This is an oversight that we’ll fix in a future release. It works for the SampleProjects, because the EGL headers are included in SampleProjects/Common/API/EGL. For your immediate purposes, you can add that folder to your project headers.

The three files gl.m, glext.m, and egl.m really do not need to be *.m files, and, with some minor adjustments, could be changed to *.c files instead. Again, we’ll make that change in a future release. However, the EAGL.m file does contain Objective-C classes, so must remain as an Objective-C file. In OpenGL ES on Apple platforms, the EAGL classes play a key role in associating the primary renderbuffer with the underlying platform graphics.

Some further use-case info might help get to the bottom of this. In your C++ only code, how would you expect to associate the OpenGL ES renderbuffer with the platform graphics on OS X, without using Objective-C? How does your code handle this under desktop OpenGL on OS X?

…Bill

[Bill Hollings]

@pemgl

You indicated earlier that you were building using El Capitan (10.11), but in this recent post, you’re indicating Yosemite (10.10).

Metal is available only on El Capitan (10.11) and later. Can you try running this under El Capitan (10.11)?

To support OS X versions that do not have Metal, you need to provide a separate implementation of OpenGL ES. The README-UserGuilde.md document includes a section on how to do this.

…Bill

[Bill Hollings]

@pemgl

Thanks for your thoughts on MetalGL.

We’ve priced MetalGL so that it is compatible with the budgets of any project, whether it be a single indie developer or a large development shop. By arranging the pricing per seat, smaller shops get a decent price, and large development shops, with larger teams and budgets, also pay according to the benefit MetalGL brings to their development team. And keep in mind that MetalGL is essentially risk-free. You only purchase a license after you have confirmed the benefits it provides, and have an app that you are essentially ready to ship!

Regarding open-source, at Brenwill, we have significant experience with providing open-source products, and your summary of the upsides and downsides is fairly accurate. However, we do understand the benefits of source access for certain projects, and do provide a source licensing option to key customers.

BTW…we do not agree with the royalty model. After all, if every tool vendor did that, it wouldn’t be long before any particular project accumulated royalties in excess of 100%! :^)

…Bill

[Bill Hollings]

@pemgl

Thanks for your thoughts about MetalGL.

MetalGL on OS X has not yet undergone Khronos’s OpenGL ES conformance test. Full conformance is indeed the intention, but we expect to wait until OpenGL ES 3 support is complete in MetalGL, and perform conformance testing then.

We agree with you that a fast, solid OpenGL ES implementation on OS X will fill a key hole in cross-platform development for both OpenGL ES and WebGL.

MetalGL‘s trial license is indeed unlimited time. We agree that developers should be confident that they are getting what the need before having to pay for a license!

…Bill

[Bill Hollings]

@pemgl

Thanks for pointing out the issue in gltypes.h with

#include “../../orig/OpenGLES/gltypes.h”

We’ll fix that in a future release.

With regards to the remaining header and linking issues, be sure to review the installation section of the README-UserGuide.md file (also available online). In particular, as described in that document, make sure the Metal framework is linked to your app, and the four files: gl.m, glext.m, egl.m, and EAGL.m from the MetalGL/OSX folder have been added to your app.

…Bill

[Bill Hollings]

@pemgl

Very strange indeed!

We’re not seeing anything like that here. I just tried downloading MetalGL 0.1.0 and running the DrawLoadDemo under OS X 10.11 Beta (15A279b) on a Macbook Pro (mid 2014), and it runs fine.

Perhaps there is an environmental issue. What version of OS X are you using, and on what kind of machine?

Also, can you ZIP up the Xcode project, post it to somewhere like Dropbox and post a link here, so we can have a look at your configuration?

…Bill

[Bill Hollings]

@le-foot

This is a shader program that has gone missing. Can you look for where you call glDeleteProgram().

Regarding your question about compatibility, different OpenGL ES implementations can sometimes behave slightly differently, and the life-cycle of a shader program that is re-linked or deleted while still being used can sometimes be a implementation-dependent. If we can nail down how it comes to disappear, we can figure out why that difference is manifesting here.

…Bill

[Bill Hollings]

@le-foot

Without seeing the source code, it’s hard to say what’s happening.

Are you deleting the shader program at some point, and then coming back to it? If so, can you try to determine under what conditions that is happening?

…Bill

[Bill Hollings]

@le-foot

This looks like the other error you encountered.

That was fixed with the MetalGL 0.10.0 release. Have you upgraded to the latest version of MetalGL?

…Bill

[Bill Hollings]

@le-foot

Does anything appear in the logs?

Some thoughts:

• Is the location 0 a valid uniform location? Where does the location value come from?
• Do you really mean to pass two 4×4 matrices (a total of 32 floats)?
• m_bufferData should be a pointer to the start of an array of 32 float values (2 x 4 x 4). You seem to show it as a single float value (not a pointer).

…Bill

[Author]

Posts