Irrlicht + OpenGL M1 [Fix Crash]

[MarvinSt]

With the current implementation, I am having issues launching Chrono on an M1. I found that it often crashes trying to initialise Irrlicht. In the current implementation, Irrlicht is first initialised with a default driver (not available on M1), if this call fails it reattempts using the OpenGL driver (which often fails in my case). If on the other hand, I directly initialise using the OpenGL driver, it launches reliably.

I.e. I changed the following section in ChVisualSystemIrrlicht.cpp

    // Create Irrlicht device using current parameter values.
    m_device = irr::createDeviceEx(m_device_params);
    if (!m_device) {
        std::cerr << "Cannot use default video driver - fall back to OpenGL" << std::endl;
        m_device_params.DriverType = irr::video::EDT_OPENGL;

        m_device = irr::createDeviceEx(m_device_params);
        if (!m_device) {
            std::cerr << "Failed to create the video driver - giving up" << std::endl;
            return;
        }
    }

to

    // Create Irrlicht device using current parameter values.
    m_device_params.DriverType = irr::video::EDT_OPENGL;

    m_device = irr::createDeviceEx(m_device_params);
    if (!m_device) {
        std::cerr << "Failed to create the video driver - giving up" << std::endl;
        return;
    }

It is probably a good idea to check whether OpenGL is available and use this as the default otherwise use the default Irrlicht driver.

[rserban]

Marvin, the order of checks you suggest would not work. The Irrlicht OpenGL device is available on most platforms, while the Direct3D one only available on Windows. If we tested like you suggested, we could never use the Direct3D device on Windows.

We could, of course, test the platform and do things differently for Windows. But that's something I'd stay away from if not absolutely necessary. I don't recall anyone else reporting this problem; granted, we do not have that many Mac users.

It'd be useful if you could dig a bit deeper into this and understand why the code crashes instead of just failing to create an Irrlicht device. What version of Irrlicht do you have and how did you install it?

[MarvinSt]

Yes, I understand. It is not a solid fix. But perhaps another mechanism can be used to check if DX is available on the given system, before attempting the call. There is no point in trying on those devices if the first call will anyway fail, right?

Unfortunately, I don’t really know how to investigate it further, it crashes when calling “createDeviceEx“ for the second time in a row. It could be some sort of timing issue, device locked or memory issue, who knows. If I execute it in the terminal I am simply getting a “bus error” and in the debugger a vague thread error when I step through the code in the debugger. I also tried implementing some additional retry logic, but that did not help either.

I installed the latest irrlicht versions (1.8.5 and 1.8.4), both behaved the same way.

If you have any suggestions on what I can try further, I am happy to debug it. This workaround has allowed me to use it without problems, it may help others.

[rainergericke]

On my Mac M1 Max, MacOS 13.1 and Irrlicht installed via homebrew I never found a problem with Irrlicht crashing. Homebrew does only install libraries in Release mode, that means you cannot debug Irrlicht code on source level. You would have to build your own debug version of irrlicht. The Irrlicht Xcode configuration is broken yet.

[MarvinSt]

That is quite strange. Not sure why we would have different behaviour. Installed it the same way and run the latest version.
If no one else has this problem, I guess it can be closed and I just use the workaround above.