Thanks. Saves me wasting any more time on this. Maybe FG will one day catch up with modern hardware - hopefully before today's modern hardware is superseded :o)
I'll point out that there's no official ARM binary for macOS either & that hardware's been around for quite a while - maybe the team don't have the hardware yet. I have built FG for macOS/ARM & there isn't a massive difference in performance between it & running under binary translation (turning off debug is what make a massive difference btw).
As far as I know, all the build hardware is VMs on x86, donated & managed by someone. ARM builds would require equivalent parallel build hardware for ARM with the ability to run macOS, Linux & Windows for ARM in VMs.
It should be possible to build FG for Windows/ARM - it would take some doing though as there are likely assumptions in the windows code & build systems that wrongly enable x86 optimisations (there are for macos)
It runs, but has the exact same graphical issues as the x86 binary on M1 - this is due to the fact that Apples OpenGL on M1 Macs is AFAIK non conformant (doesn't pass the OpenGL conformancy tests), due to the fact that it's a translation layer on top of Metal (like zink is a translation layer to run OpenGL on Vulkan, and DXVK is a translation layer to run DX{9,10,11} on Vulkan)
FG can be compiled to run on Linux/ARM just fine btw - I keep meaning to setup some AppImage builds for aarch64 but keep getting distracted by other stuff
Ah well - but thanks for going it some thought. Looks like I'll have to use FG solely for FlightNights and X-Plane for anything else. DCS Also won't run on Arm/Win 11 pro.
My reading of this is that it was a workaround for getting Photoshop to run better on Win10/Arm and I don't have Win10.
I've read that PS runs on Win11 anyway but I have Photoshop on my Mac so I haven't installed it. It's one of the few apps on the Microsoft Store that says "This product should work on your device".
Tried the OpenGL Pack but no help - probably because FGFS is not native Arm anyway. The reviews for this Pack are pretty damning.
I think Adobe recompiled their app as native recently
I was looking at trying to compile FG on win11 arm in a vm on my mac, but for some reason the windows store isn't present so I can't install the opengl compatibility pack
the compatibility pack only supports opengl 3.3 on dx12 which is a bit crap - it's actually a part of the mesa open source project (which provides all the open source drivers for linux etc) - it's status is described here
Ah - you're running win11 in parallels. I have vmware fusion for macos, but I haven't tried installing win11 in it yet - I was using UWP
X-plane 12 uses vulkan & zink (an open source library that translates from opengl to vulkan)
At the moment I'mm investigating whether MS Visual Studio can cross compile FG for win11 on arm (it should be able to, but the process might be torturous)
As an experiment I installed Debian ARM in a VMware VM on my M1 Mac & it works fine - the graphics look the same as normal Linux. The framerate isn't great, but it works & looks normal in ALS (tested next btw)
I installed Win 11 ARM in a trial version of Parallels & worked out that it's the Flightgear installer thats failing.
So, I grabbed a full install of FG 2020.3.18, zipped it up & transferred it over to the Win11 ARM VM & installed the opengl compatibility layer & guess what?
FG runs, but doesn't render in anyway remotely correctly - this may be an issue with the opengl layer or the parallels driver - no idea
So maybe the compatibility layer will improve (maybe pigs will fly), or maybe the driver will improve later, but for now this is a bit of a dead end
So compiling for ARM isn't necessary as it runs just fine if you grab a preinstalled copy from Win 11 x86_64 - this was going to be a headache anyway as pretty much everything (boost, qt5, plib, osg etc would have to be compiled and/or ported from scratch)
I think the main immediate issue is that FG is OpenGL based for its graphics. Adobe is big enough to sort out something for PS on Win/Arm - and it was obviously felt worth the effort. AdobePS has been running on Apple silicon for a while now so I think their interest in OpenGL will wane. I guess MS will also gradually phase it out. XP went over to Vulcan some time ago for Win versions. It was a massive task to move to Vulcan/Metal for XP so it's hard to see FG having the resources for it. I'm working on the assumption that what I have is as good as it's likely to get.
Longer term, Apple will eventually stop supporting Intel code via Rosetta. They normally do after giving developers and users a reasonable time to upgrade. When that happens, I'll have to dust off my old Intel-based Mac mini.
Yeah, FG uses OpenGL, mostly indirectly through OpenSceneGraph - the Vulkan replacement of that (VulkanSceneGraph) isn't mature yet & would require a rewrite of a lot of code.
FG is cross-platform, so the only options are OpenGL or Vulkan
Like I mentioned earlier - it's mostly about drivers & conformance. It's sometimes easier to think of conformance as predictability - you want to know that when you use a particular operation that it comes out the way your expect - that's what conformance tests are for
It's why I tested Debian in a VM in VMware on the Mac Studio - VMware has a Metal backend renderer, but the VMSVGA interface & driver spec are well known & there are multiple implementions - Linux has it built in via Mesa. So the only implementation that appears correct is Linux in a VM. Apple is deprecating OpenGL & don't care about cross platform standards.
BTW there is a Vulkan layer called MoltenVK for macOS but it's hamstrung by running on Metal.
By the way - you may know about Zink, a project supported by Valve that runs OpenGL on Vulkan - it's actually used to provide a conformant OpenGL implemenation by a vendor so they only have to write Vulkan drivers.
Zink is used by X-Plane 12 on WIndows as AMDs OpenGL drivers cause issues with some XP12 plugins - FG may need to use this in future if OpenGL goes the way of the dodo on Mac.
Comments
Doesn't look like there's a binary:
https://forum.flightgear.org/viewtopic.php?t=40952&p=406379
Thanks. Saves me wasting any more time on this. Maybe FG will one day catch up with modern hardware - hopefully before today's modern hardware is superseded :o)
I'll point out that there's no official ARM binary for macOS either & that hardware's been around for quite a while - maybe the team don't have the hardware yet. I have built FG for macOS/ARM & there isn't a massive difference in performance between it & running under binary translation (turning off debug is what make a massive difference btw).
As far as I know, all the build hardware is VMs on x86, donated & managed by someone. ARM builds would require equivalent parallel build hardware for ARM with the ability to run macOS, Linux & Windows for ARM in VMs.
It should be possible to build FG for Windows/ARM - it would take some doing though as there are likely assumptions in the windows code & build systems that wrongly enable x86 optimisations (there are for macos)
Did you manage to get an Apple Silicon/M1 Mac version to run ok?
It runs, but has the exact same graphical issues as the x86 binary on M1 - this is due to the fact that Apples OpenGL on M1 Macs is AFAIK non conformant (doesn't pass the OpenGL conformancy tests), due to the fact that it's a translation layer on top of Metal (like zink is a translation layer to run OpenGL on Vulkan, and DXVK is a translation layer to run DX{9,10,11} on Vulkan)
FG can be compiled to run on Linux/ARM just fine btw - I keep meaning to setup some AppImage builds for aarch64 but keep getting distracted by other stuff
Ah well - but thanks for going it some thought. Looks like I'll have to use FG solely for FlightNights and X-Plane for anything else. DCS Also won't run on Arm/Win 11 pro.
BTW have you tried the Compatibility Troubleshooter on ARM Win11? I've no idea if it would make a difference though....
https://learn.microsoft.com/en-us/windows/arm/apps-on-arm-program-compat-troubleshooter
Just tried that. Same issue - not an x86/x64 app.
Damn - theres a hint in the MS wiki there that OpenGL 1.1 apps aren't supported by the translator, which kinda sucks
Right so it looks as though Windows on ARM only really supports DX12, but they used an Open Source solution to translate:
https://devblogs.microsoft.com/directx/announcing-the-opencl-and-opengl-compatibility-pack-for-windows-10-on-arm/
It should be available for win11 - not sure if it will make a difference though - may be worth a try?
My reading of this is that it was a workaround for getting Photoshop to run better on Win10/Arm and I don't have Win10.
I've read that PS runs on Win11 anyway but I have Photoshop on my Mac so I haven't installed it. It's one of the few apps on the Microsoft Store that says "This product should work on your device".
Tried the OpenGL Pack but no help - probably because FGFS is not native Arm anyway. The reviews for this Pack are pretty damning.
Damn
I think Adobe recompiled their app as native recently
I was looking at trying to compile FG on win11 arm in a vm on my mac, but for some reason the windows store isn't present so I can't install the opengl compatibility pack
the compatibility pack only supports opengl 3.3 on dx12 which is a bit crap - it's actually a part of the mesa open source project (which provides all the open source drivers for linux etc) - it's status is described here
https://docs.mesa3d.org/drivers/d3d12.html
I'd love to muck about with a low end win 11 arm device, but I can't find anything cheap
Does X-plane 12 run on win 11 arm?
Seems not:
Ah - you're running win11 in parallels. I have vmware fusion for macos, but I haven't tried installing win11 in it yet - I was using UWP
X-plane 12 uses vulkan & zink (an open source library that translates from opengl to vulkan)
At the moment I'mm investigating whether MS Visual Studio can cross compile FG for win11 on arm (it should be able to, but the process might be torturous)
As an experiment I installed Debian ARM in a VMware VM on my M1 Mac & it works fine - the graphics look the same as normal Linux. The framerate isn't great, but it works & looks normal in ALS (tested next btw)
I installed Win 11 ARM in a trial version of Parallels & worked out that it's the Flightgear installer thats failing.
So, I grabbed a full install of FG 2020.3.18, zipped it up & transferred it over to the Win11 ARM VM & installed the opengl compatibility layer & guess what?
FG runs, but doesn't render in anyway remotely correctly - this may be an issue with the opengl layer or the parallels driver - no idea
So maybe the compatibility layer will improve (maybe pigs will fly), or maybe the driver will improve later, but for now this is a bit of a dead end
So compiling for ARM isn't necessary as it runs just fine if you grab a preinstalled copy from Win 11 x86_64 - this was going to be a headache anyway as pretty much everything (boost, qt5, plib, osg etc would have to be compiled and/or ported from scratch)
I think the main immediate issue is that FG is OpenGL based for its graphics. Adobe is big enough to sort out something for PS on Win/Arm - and it was obviously felt worth the effort. AdobePS has been running on Apple silicon for a while now so I think their interest in OpenGL will wane. I guess MS will also gradually phase it out. XP went over to Vulcan some time ago for Win versions. It was a massive task to move to Vulcan/Metal for XP so it's hard to see FG having the resources for it. I'm working on the assumption that what I have is as good as it's likely to get.
Longer term, Apple will eventually stop supporting Intel code via Rosetta. They normally do after giving developers and users a reasonable time to upgrade. When that happens, I'll have to dust off my old Intel-based Mac mini.
Yeah, FG uses OpenGL, mostly indirectly through OpenSceneGraph - the Vulkan replacement of that (VulkanSceneGraph) isn't mature yet & would require a rewrite of a lot of code.
FG is cross-platform, so the only options are OpenGL or Vulkan
Like I mentioned earlier - it's mostly about drivers & conformance. It's sometimes easier to think of conformance as predictability - you want to know that when you use a particular operation that it comes out the way your expect - that's what conformance tests are for
It's why I tested Debian in a VM in VMware on the Mac Studio - VMware has a Metal backend renderer, but the VMSVGA interface & driver spec are well known & there are multiple implementions - Linux has it built in via Mesa. So the only implementation that appears correct is Linux in a VM. Apple is deprecating OpenGL & don't care about cross platform standards.
BTW there is a Vulkan layer called MoltenVK for macOS but it's hamstrung by running on Metal.
By the way - you may know about Zink, a project supported by Valve that runs OpenGL on Vulkan - it's actually used to provide a conformant OpenGL implemenation by a vendor so they only have to write Vulkan drivers.
Zink is used by X-Plane 12 on WIndows as AMDs OpenGL drivers cause issues with some XP12 plugins - FG may need to use this in future if OpenGL goes the way of the dodo on Mac.