Forum Replies Created
2016-01-12 at 11:58 am in reply to: can MetalGL support opengl-es 2.0 and Metal API in one App? #775
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
For more info, you can review the Device Platforms and OpenGL System Classes section of the
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
You can use
GLKView, but follow the instructions in the *EAGL and GLKit System Classes* section of the
Support for OpenGL ES 3.0 is a priority, but at this point we can’t provide a release date.
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.mddocument 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.
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?
…Bill2015-11-06 at 10:10 am in reply to: License question concerning the standalone MetalGLShaderConverter #754
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).
…Bill2015-11-06 at 9:37 am in reply to: [***MetalGL ERROR***] GL_INVALID_OPERATION. glTexParameteri() #751
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:
…Bill2015-11-05 at 9:23 pm in reply to: [***MetalGL ERROR***] GL_INVALID_OPERATION. glTexParameteri() #748
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
GLKitare you using? The only part of
GLKitthat MetalGL supports is
GLKView. If you are using
README-UserGuide.mddocument explains how to use it with MetalGL. Specifically, if you have an Storyboard that uses GLKView, you need to establish and use an empty
GLKViewsubclass, so that the Storyboard loader won’t try to load the default system
GLKViewclass (and thereby bypass the MetalGL overrides).
If 2bpp PVRTC textures are critical, we can look to add support for them sooner rather than later.
…Bill2015-11-05 at 3:52 pm in reply to: [***MetalGL ERROR***] GL_INVALID_OPERATION. glTexParameteri() #746
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
DEBUGbuild setting, or unless you have enabled either the
GL_DEBUG_MODE_MGLMetalGL capabilities (using
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.
…Bill2015-11-05 at 2:56 pm in reply to: Some issues while trying out MetalGL in a large project #745
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.
…Bill2015-10-02 at 12:38 pm in reply to: undefined symbols – _MTLCreateSystemDefaultDevice _glActiveShaderProgramEXT etc #735
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
ES2Rendererclasses are implemented in Apple’s GLEssentials sample code. You can download this sample and run it with MetalGL under iOS.
The way the
EAGLViewclass 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
MGLGLKViewclass does, both on iOS and OS X, but through a
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.
…Bill2015-10-01 at 10:29 am in reply to: undefined symbols – _MTLCreateSystemDefaultDevice _glActiveShaderProgramEXT etc #733
It looks like you’re using a windowing library that we are not familiar with. Have a look at the
DrawLoadDemoto understand how the
DemoViewclass is constructed. It’s based on
MGLGLKView, which behaves like Apple’s
GLKViewclass, but handles creating the framebuffers for rendering to Metal.
If you can’t use the
MGLGLKViewclass, 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?
…Bill2015-09-29 at 2:35 pm in reply to: undefined symbols – _MTLCreateSystemDefaultDevice _glActiveShaderProgramEXT etc #729
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.
…Bill2015-09-28 at 10:19 am in reply to: undefined symbols – _MTLCreateSystemDefaultDevice _glActiveShaderProgramEXT etc #724
egl.hfile 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
egl.mreally do not need to be
*.mfiles, and, with some minor adjustments, could be changed to
*.cfiles instead. Again, we’ll make that change in a future release. However, the
EAGL.mfile does contain Objective-C classes, so must remain as an Objective-C file. In OpenGL ES on Apple platforms, the
EAGLclasses 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?
…Bill2015-09-28 at 9:16 am in reply to: DrawLoadDemo – dyld: Symbol not found: ___NSDictionary0__ #723
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.mddocument includes a section on how to do this.
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%! :^)
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!
…Bill2015-09-27 at 2:18 pm in reply to: undefined symbols – _MTLCreateSystemDefaultDevice _glActiveShaderProgramEXT etc #718
Thanks for pointing out the issue in
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.mdfile (also available online). In particular, as described in that document, make sure the Metal framework is linked to your app, and the four files:
MetalGL/OSXfolder have been added to your app.
…Bill2015-09-27 at 10:15 am in reply to: DrawLoadDemo – dyld: Symbol not found: ___NSDictionary0__ #717
Very strange indeed!
We’re not seeing anything like that here. I just tried downloading MetalGL 0.1.0 and running the
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?
…Bill2015-09-22 at 5:48 pm in reply to: EAGLContext renderbufferStorage:fromDrawable fails #705
This is a shader program that has gone missing. Can you look for where you call
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.
…Bill2015-09-22 at 5:28 pm in reply to: EAGLContext renderbufferStorage:fromDrawable fails #703
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?
…Bill2015-09-22 at 5:04 pm in reply to: EAGLContext renderbufferStorage:fromDrawable fails #7012015-09-21 at 8:39 pm in reply to: EAGLContext renderbufferStorage:fromDrawable fails #695
Does anything appear in the logs?
- Is the location
0a 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_bufferDatashould 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).
- Is the location