macOS Metal crash during initialization #251
Comments
|
P.S. Here's some information about the Metal capabilities of that machine: |
|
I didn't know Metal-capable NVIDIA GPUs existed at all. That shader uses But this is definitely an Ogre bug because Ogre should not abort loading, it should log the error, mark the material as unsupported and move on (this isn't a fatal error; this is the same as having a shader compiler error: as long as the material isn't used, all is well). That material is only used in VR, as its name suggests. A seemingly simple way to repro on any machine the error would be to do: To see what parent function is missing a try()catch() pair (it should be far up, i.e. when parsing materials; because we definitely want to throw if we try to use this shader during rendering). |
darksylinc
added
bug
|
By the way, this Mac has Intel Iris Pro integrated graphics as well as the Nvidia card. That wouldn't be better for Ogre, would it? |
|
Correction, my colleague now reports that the Sample_Tutorial01_Initialization app does run now that he supplied the SDL dylib that had been missing. It's just an app that I built without SDL that crashes. Yet Sample_Tutorial01_Initialization does contain HiddenAreaMeshVr.material in its resources, so I'm confused. |
|
I'd expect the Intel GPU to probably support this feature and hence not crash, but when it comes to performance the NVIDIA card should win. AFAIK there is a switch to select which GPU to use when the graphics settings prompt appears (Eugene added this feature). |
|
That |
I'm a bit confused by this: So it's not crashing for him anymore? |
|
That's right, Sample_Tutorial01_Initialization is not crashing for him any more. That was a "red herring". The actual Metal crash was in a different app that I built without using SDL. I made him a new build omitting HiddenAreaMeshVr.material and RadialDensityMask.material from the resources, and that made it not crash. |
|
The only thing that comes to mind is just a coincidence: That was the last material it parses before crashing due to something unrelated (like SDL) |
|
Let's review: Initially, my app was having a fatal Metal exception just after the Ogre.log said it had compiled HiddenAreaMeshVr_vs_Metal. I removed that, and then there was a fatal exception just after the log said it had compiled RadialDensityMask_vs_Metal. I removed that, and no more fatal exception. And those just happen to be the exact two vertex shaders that use |
|
Oh, on taking another look at the log for Tutorial01, for some reason it doesn't actually compile those shaders it just has for the General group. I'll ask the guy with the Nvidia Mac to try Tutorial02. |
|
As I suspected, Tutorial02 shows the same Metal exception right after "HiddenAreaMeshVr_vs_Metal compiled successfully" when the Nvidia card is selected as the rendering device. When Intel graphics are selected, it runs successfully. |
|
I see, then we're missing a try/catch block at a higher level |
|
That certainly sounds like an improvement. But I wonder whether there is any way to give a more helpful report of what’s actually wrong? If an unavailable feature is being used in these vertex shaders, why does the compile succeed? |
|
The majority of times that step fails because of a driver error/bug. The driver reports what's wrong in NSError (which we log and in this case it says That error makes it sound like we should specificy whether the PSO uses tri-lists, tri strips, indexed or not, etc. But I don't know how to specify that (but it's not worth it because that GPU is not powerful enough for VR anyway) |
|
Fixed! Thanks for the report! |
|
Sorry, there is still a problem. My colleague with the Nvidia GPU still reports a crash. So on my own machine, I changed line 393 of OgreMetalProgram.mm to and the immediate exception gets caught but leads to more problems later. The final part of Ogre.log is: and then the program crashes at line 374 of OgreMetalProgram.mm, |
|
Ok that crash makes little sense because: shader->load();
assert( dynamic_cast<MetalProgram*>( shader->_getBindingDelegate() ) );There multiple scenarios:
Note that on my system when I tried it worked fine: the exception is raised and it later continues normally (i.e. I could not repro your problem). More info on what "shader" is would shed some light on why it is asserting (also the contents of variables, e.g. what's in |
|
Are you sure you tested the same way I did? Earlier in this thread, you mentioned the idea of saying whereas I said that I used note that it's the vertex shader, not the pixel shader. When the assertion fails, |
|
Sneaky!!! I thought the VS was succeeding but then failing when paired with PS. I can see why it would fail for VS first.
D'oh! Now it makes sense. Yeah I see the problem now. I'll try to repro the problem again. Obviously we're not handling the case where a valid shader reflection pair was provided but that pair failed to compile. |
|
OK I coded this one blind, in other words I didn't test it. I'll leave testing to you 😝 Hopefully it works since it's wasn't a hard error (famous last words), it should be working now |
|
Still no good. In the function if( !pso || error || mName == "Ogre/VR/HiddenAreaMeshVr_vs_Metal" )and in the main program I added a try/catch block around initialization: try
{
graphicsSystem.initialize( "Tutorial 02: Variable Framerate" );
}
catch (Ogre::Exception& ex)
{
Ogre::LogManager::getSingleton().logMessage(
"exception caught from graphicsSystem.initialize:");
Ogre::LogManager::getSingleton().logMessage( ex.getFullDescription() );
return 1;
}End of Ogre.log: |
|
Please check compatibility with list here: https://support.apple.com/en-us/HT208898 |
While true, I'd like to keep the ticket open until fixed, since the ticket is revealing we're incorrectly handling errors; and I have the feeling it's going to bite us in the future if left unfixed (however it's currently low priority for me). |
|
@dyunchik The support article you link to says it is for Mac Pro, not all Macs. The Mac with the NVIDIA GeForce GT 750M is a MacBook Pro, different machine. I'm not sure exactly which model my colleague has, but one such model is the 15-inch mid-2014 model with specs here: https://everymac.com/systems/apple/macbook_pro/specs/macbook-pro-core-i7-2.8-15-dual-graphics-mid-2014-retina-display-specs.html This model can go as far as Big Sur (it goes to 11). According to this Apple page, Metal 2 is supported on MacBook Pros from mid 2012 on. |
You're right. |
Log the errors/failures instead of raising an exception, which causes a crash if the GPU doesn't support a specific feature despite the shader being valid. Fixes #251
|
This issue has been fixed on both 2.4 & 2.3 branches. Thanks for all the info! |
System Information
Detailled description
A colleague gets an immediate crash when opening an Ogre app, even Sample_Tutorial01_Initialization. The same apps work on my Mac running the same version of macOS. One difference is that his Mac has Nvidia graphics, while mine has AMD graphics. Both have Intel CPUs, not Apple Silicon.
Ogre.log
Callstack
The text was updated successfully, but these errors were encountered: