Dynamically load MetalFX. Disable Metal and Vulkan renderers in simulator builds.

[bruvzg]

Supersede #102151

• Reverts iOS: Weak-link MetalFX #101614 and partially reintroduce [macOS, iOS] Dynamically load MetalFX. #101590
  Weak linking works only if library is present when building, it's not the case for simulator, so Xcode project build always fail.
• Disables Metal and Vulkan renderers in dedicated simulator builds.
  Neither was functional due to lack of image cube map arrays support in simulated GPU.
• Fixes generated simulator library creation on export in some case.

Simulator never worked with Vulkan and Metal renderers, but is working with OpenGL.

The problem is, we are always using the same library which includes all renderers, regardless of renderer. Also, our OSXCross can't build dedicated simulator library, so for official templates, a device library is converted to simulator library on export (by patching LC_BUILD_VERSION load commands).

I'm not sure if we should introduce all this hacky stuff, but also not sure if there are any other options:

We can:

• Make a separate iOS builds for Metal, Vulkan and OpenGL (and only OpenGL build will have simulator support), and only export one specific library. This is likely a more clean option, but will triple iOS export template size, and will make fallback from Metal/Vulkan to OpenGL completely impossible (it's not working right now in any case, but there seems to be some interest in it).
• Remove device to simulator library conversion, disable Vulkan and Metal renderers in simulator builds. Update docs to make it clear that simulator is not supported by official export template, support OpenGL only, and you have to build it yourself if you need it.
• Drop simulator support entirely. What it is useful for? It's not representative of any real device capabilities, and you can run and test iOS apps on Apple Silicon macs directly, without any simulated GPU limitations.

[akien-mga]

Drop simulator support entirely. What it is useful for? It's not representative of any real device capabilities, and you can run and test iOS apps on Apple Silicon macs directly, without any simulated GPU limitations.

If you can run and test iOS apps on Apple Silicon macs, and the simulator build can't support Metal, I think that's making a strong case for simply dropping support for it.

Most users targeting iOS should be using Metal from now on, and will likely have Apple Silicon hardware. OpenGL is deprecated by Apple so adding hack to supports a simulator option that only works for a deprecated renderering API doesn't seem too useful. Overall the Apple philosophy is to move fast and deprecate things faster, so I don't think we should jump through hoops to support what they don't want us to support.

[bruvzg]

I'm mostly in favor of option two: remove it from official builds and exporter, but keep OpenGL only simulator version buildable, add notes to the docs how top use it.

[AdriaandeJongh]

+1 to drop simulator support. For comparison, exporting for simulator in Unity would always require settings changes and various hacks and adjustments to get going, only to find that simulator performance is terrible and therefore useless.

[bruvzg]

#102179