added support for aarch64 ios simulator

[geertbleyen]

PR checklist:

• [X] make succeeds (on *nix)
• [X] make reftests succeeds
• [X] tested examples with the following backends: metal

Xcode uses an aarch64 simulator on m1 Apple devices, instead of an x86_64 simulator. This caused the metal backend to incorrectly load the real device's shaders, leading to runtime errors. As far as I can tell, the only way to differentiate between an aarch64 simulator target and an aarch64 device target, is to use the 'abi' target property. this only works on nightly toolchains unfortunately. If there are better ways to do this, I gladly want to hear it.

[geertbleyen]

FYI: in the meantime I've been working on an alternative workaround that doesn't require nightly feature -> https://github.com/geertbleyen/gfx/tree/fix/aarch64-apple-ios-sim_alt-fix

Can you please check if that is better solution? I used a verbatim target name check (shaders-sys is doing this too, so maybe that's an acceptable solution here too).

[kvark]

Since gfx-rs is now in maintenance mode, would you mind porting this to wgpu instead?

[geertbleyen]

Unless I'm missing something, it doesn't seem like either of my possible fixes apply to wgpu's metal backend, as it doesn't load a precompiled shader library like the gfx metal backend does (which is were this bug occurs) It doesn't seem like this switching from gfx-hal to wgpu-hal is quite trivial and wgpu-hal doesn't support the different backends we currently would need in our project. Our deadlines don't allow us the time to make this switch and wait for the needed backends to be ready.

[geertbleyen]

I've pushed my alternative fix that doesn't rely on nightly features

[kvark]

That's all reasonable. Fwiw, wgpu-hal has all the backends that gfx-hal has, except DX11, which will hopefully come soon. And the backends that it has are more solid. Something to consider for future plans.