September 9, 2015 at 7:23 pm #642
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?
ThanksSeptember 9, 2015 at 8:40 pm #643
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
CALayerunderlying your view is not compatible with Metal.
How is your view created, and how does it create its underlying
Make sure that the code that creates the
<QuartzCore/CoreAnimation.h>, and that the path to
CAEAGLLayer.his being redirected to
RedirectHeaders/include/QuartzCore/CAEAGLLayer.h, so that
CAEAGLLayerwill be redefined to
…BillSeptember 10, 2015 at 2:53 pm #644
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.September 11, 2015 at 12:32 pm #645
And are you seeing an error message in the console logs?
If Metal is active, when
false, it spits out an error message to the console log. The error message will either indicate that the drawable is not a
CAMetalLayeror that the target is not
If Metal is not active, then the
falseis arising from the native
…BillSeptember 11, 2015 at 5:21 pm #646
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!September 14, 2015 at 1:02 pm #648
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.mddoc). It won’t work if the
GetSystemContext()function comes from an pre-compiled library, and is returning an instance of an OpenGL system class.
…BillSeptember 14, 2015 at 1:57 pm #649
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!September 14, 2015 at 2:05 pm #651
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.mddocument. 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.
…BillSeptember 14, 2015 at 3:09 pm #652
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:134September 14, 2015 at 3:17 pm #653September 14, 2015 at 3:33 pm #654
This was in the console:
Sep 14 12:29:33 testiPad diagnosticd <Error>: error evaluating process info - pid: 1625, puniqueid: 1625 Sep 14 12:29:33 testiPad com.apple.xpc.launchd (UIKitApplication:com.MetalGLTestApp[0xf895]) <Notice>: Service exited due to signal: Abort trap: 6 Sep 14 12:29:33 testiPad SpringBoard <Warning>: Application 'UIKitApplication:com.MetalGLTestApp[0xf895]' crashed. Sep 14 12:29:33 testiPad UserEventAgent <Warning>: 10830873922631: id=com.MetalGLTestApp pid=1625, state=0 Sep 14 12:29:33 testiPad ReportCrash <Notice>: Formulating report for corpse MetalGLTestApp Sep 14 12:29:33 testiPad ReportCrash <Warning>: saved type '109_MetalGLTestApp' report (3 of max 25) as /var/mobile/Library/Logs/CrashReporter/MetalGLTestApp_2015-09-14-122933_testiPad.ipsSeptember 15, 2015 at 11:27 am #655September 15, 2015 at 1:52 pm #656
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.September 15, 2015 at 3:25 pm #658
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?
…BillSeptember 15, 2015 at 3:29 pm #659
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:178September 15, 2015 at 6:39 pm #660
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?
…BillSeptember 20, 2015 at 10:45 pm #673
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.
…BillSeptember 21, 2015 at 6:31 pm #685
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 ) );
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?September 21, 2015 at 8:39 pm #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).
…BillSeptember 22, 2015 at 3:00 pm #700
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?September 22, 2015 at 5:04 pm #701September 22, 2015 at 5:21 pm #702
Hi Bill, yes I’ve upgraded to the latest MetalGL. It never drew before, but now it draws for a little while.September 22, 2015 at 5:28 pm #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?
…BillSeptember 22, 2015 at 5:36 pm #704
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?September 22, 2015 at 5:48 pm #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.
- Is the location
The forum ‘MoltenGL Support’ is closed to new topics and replies.