[le-foot]

Hi,

I have a call to – EAGLContext (BOOL)renderbufferStorage in my code that when using MetalGL, returns false. Reverting to OpenGL, it will return true. I was wondering if anyone has an idea why this might be?

Thanks

[Bill Hollings]

@le-foot

If renderbufferStorage:fromDrawable: returns false, then you should be seeing an error logged in the console. It should provide you with more info.

If the error message indicates that the Drawable must be an instance of CAMetalLayer, the problem is that the CALayer underlying your view is not compatible with Metal.

How is your view created, and how does it create its underlying CALayer?

Make sure that the code that creates the CALayer imports <QuartzCore/CAEAGLLayer.h>, <QuartzCore/QuartzCore.h> or <QuartzCore/CoreAnimation.h>, and that the path to CAEAGLLayer.h is being redirected to RedirectHeaders/include/QuartzCore/CAEAGLLayer.h, so that CAEAGLLayer will be redefined to MGLCAEAGLLayer.

…Bill

[le-foot]

Thanks for your reply, Bill. My this is my view:

m_view
<EAGLView: 0x145e79170; frame = (0 0; 703.5 768); autoresize = W+H; layer = <CAMetalLayer: 0x145e798f0>>

Seems like it has a CAMetalLayer.

[Bill Hollings]

@le-foot

And are you seeing an error message in the console logs?

If Metal is active, when renderbufferStorage:fromDrawable: returns false, it spits out an error message to the console log. The error message will either indicate that the drawable is not a CAMetalLayer or that the target is not GL_RENDERBUFFER.

If Metal is not active, then the false is arising from the native EAGLContext.

…Bill

[le-foot]

Hi Bill,

I’m not seeing any error message in the console logs. This is the function call that I have, and as you can see from the above, layer is CAMetalLayer:

[GetSystemContext() renderbufferStorage: GL_RENDERBUFFER fromDrawable: layer];

If I’m not using MetalGL, then this doesn’t occur.

Thanks!

[Bill Hollings]

@le-foot

MetalGL works by replacing the OpenGL functions and classes with compatible components that replace the native OpenGL functionality with equivalent functionality based on Metal.

What is the class of the return value of your GetSystemContext() function? It needs to be an instance of MGLEAGLContext. That will happen if the implementation of the GetSystemContext() function has access to the MetalGL headers (as explained in the README.md doc). It won’t work if the GetSystemContext() function comes from an pre-compiled library, and is returning an instance of an OpenGL system class.

…Bill

[le-foot]

You’re right: GetSystemContext() only returns an instance of EAGLContext. Any chance you might know if I missed a step setting this up?

Thank you for your replies!

[Bill Hollings]

@le-foot

Make sure the Xcode project (or subproject) in which the GetSystemContext() function is implemented is configured to use MetalGL as described in the installation section of the README.md document. Make sure that the user header override build settings parts of that configuration are set to be recursive, and if you have multiple targets in your project, make sure they are either set at the project level, or set for each target that need them.

…Bill

[le-foot]

That fixed it! I missed a project. Thank you!

However, I seem to have a new problem: the app crashes with the following stack:

Thread 0 Crashed:
0   libsystem_kernel.dylib        	0x000000019ab131e0 0x19aaf8000 + 111072
1   libsystem_pthread.dylib       	0x000000019abdcf0c 0x19abd8000 + 20236
2   libsystem_c.dylib             	0x000000019aa86b78 0x19aa24000 + 404344
3   libsystem_c.dylib             	0x000000019aa5bb28 0x19aa24000 + 228136
4   Metal                         	0x00000001887a3494 0x18877c000 + 160916
5   Metal                         	0x00000001887a2a88 0x18877c000 + 158344
6   AGXMetalG3                    	0x0000000102b6c120 0x102b5c000 + 65824
7   MetalGLTestApp                   	0x0000000100201294 0x1000cc000 + 1266324

Xcode stack with symbols:

#0	0x000000019ab131e0 in __pthread_kill ()
#1	0x000000019abdcf0c in pthread_kill ()
#2	0x000000019aa86b78 in abort ()
#3	0x000000019aa5bb28 in __assert_rtn ()
#4	0x00000001887a3494 in MTLReportFailure ()
#5	0x00000001887a2a88 in -[MTLRenderPipelineDescriptorInternal validateWithDevice:] ()
#6	0x0000000102b6c120 in ___lldb_unnamed_function215$$AGXMetalG3 ()
#7	0x000000010020d294 in -[MGLRenderPipelineState makeMTLPipelineState] at /Users/bill/Documents/Dev/iOSProjects/MetalGL/MetalGL/MetalGL/MetalGL/GPUState/MGLRenderPipelineState.m:178
#8	0x0000000100335220 in MetalGLTestApp::PrepareShaders() at /Volumes/AppleSrc/MetalGLTestApp.cpp:134

[Bill Hollings]

@le-foot

Was an error output to the log?

…Bill

[le-foot]

This was in the console:

Sep 14 12:29:33 testiPad diagnosticd[81] <Error>: error evaluating process info - pid: 1625, puniqueid: 1625
Sep 14 12:29:33 testiPad com.apple.xpc.launchd[1] (UIKitApplication:com.MetalGLTestApp[0xf895][1625]) <Notice>: Service exited due to signal: Abort trap: 6
Sep 14 12:29:33 testiPad SpringBoard[1270] <Warning>: Application 'UIKitApplication:com.MetalGLTestApp[0xf895]' crashed.
Sep 14 12:29:33 testiPad UserEventAgent[23] <Warning>: 10830873922631: id=com.MetalGLTestApp pid=1625, state=0
Sep 14 12:29:33 testiPad ReportCrash[1626] <Notice>: Formulating report for corpse[1625] MetalGLTestApp
Sep 14 12:29:33 testiPad ReportCrash[1626] <Warning>: saved type '109_MetalGLTestApp' report (3 of max 25) as /var/mobile/Library/Logs/CrashReporter/MetalGLTestApp_2015-09-14-122933_testiPad.ips

[Bill Hollings]

@le-foot

Are you able to ZIP up the Xcode project and post it to somewhere like Dropbox, so we can have a look at it?

If you’re concerned about posting it publicly, you can post it privately, and then send a link to support@metalgl.com.

…Bill

[le-foot]

Hi Bill,

Thanks for following up – unfortunately I’m working with proprietary and licenced source code with my test app and I’m unable to freely release the project source code.

[Bill Hollings]

@le-foot

Okay…if you’re able to replicate the error in a less proprietary app, we can have a look.

Otherwise, the problem is happening inside Metal during the creation of a MTLRenderPipelineState. If you are running the app in Release mode, can you try running it in Debug mode instead, to get Metal to output more in the logs, and then post them here?

…Bill

[le-foot]

Hi Bill,

I’m running it through Xcode’s debugger, and I found that the error is actually the same as the Apple Sample code thread:

[mgl-info] Changed size of renderbuffer 1 to (1407, 1536)
/BuildRoot/Library/Caches/com.apple.xbs/Sources/Metal/Metal-54.30/Framework/MTLRenderPipeline.mm:1061: failed assertion 'No valid pixelFormats set.'

The stack is:

#4	0x00000001887a3494 in MTLReportFailure ()
#5	0x00000001887a2a88 in -[MTLRenderPipelineDescriptorInternal validateWithDevice:] ()
#6	0x0000000102de4120 in ___lldb_unnamed_function215$$AGXMetalG3 ()
#7	0x0000000192018ac4 in -[MTLDebugDevice _newRenderPipelineStateWithDescriptor:options:reflection:error:] ()
#8	0x0000000192018c28 in -[MTLDebugDevice newRenderPipelineStateWithDescriptor:options:reflection:error:] ()
#9	0x0000000100195294 in -[MGLRenderPipelineState makeMTLPipelineState] at /Users/bill/Documents/Dev/iOSProjects/MetalGL/MetalGL/MetalGL/MetalGL/GPUState/MGLRenderPipelineState.m:178

[Bill Hollings]

@le-foot

Are you running this on a device with iOS 9? If so, there is a known issue with a change to the Metal API on iOS 9 that causes the pixel format error.

This is fixed in the MetalGL release that is due out at the end of this week.

In the meantime, do you have a device running iOS 8 that you can test with?

…Bill

[Bill Hollings]

The latest release of MetalGL is out, and includes a fix for the iOS 9 issue mentioned above.

MetalGL 0.10.0 can be downloaded here.

…Bill

[le-foot]

Hi Bill,

Things are looking great! However, one issue has come up – after drawing one frame, I have a call to glUniformMatrix4fv:

glUniformMatrix4fv( location, count, GL_FALSE, ( m_bufferData ) );

values are:

location: 0
count: 2
m_bufferData: -1.509

The call to “mglUniformMatrix4fv()” results in a crash: EXC_BAD_ACCESS (code=1, address=0x1475c310). Does that mean anything to you?

[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

[le-foot]

Nothing appears in the logs, and location value 0 should be ok. I will investigate further. In another render task, it often crashes after about 10 seconds with this error:

[***MetalGL ERROR***] GL_INVALID_VALUE. glDrawArrays(): Shader program 2 does not exist

Do you know what this means?

[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

[le-foot]

Hi Bill, yes I’ve upgraded to the latest MetalGL. It never drew before, but now it draws for a little while.

[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

[le-foot]

No, I’ve left the glDeleteShader() calls commented out. It runs fine on OpenGL; I would imagine if a shader program is deleted unexpectedly, it would also crash if I’m not using MetalGL?

[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

[Author]

Posts