Comment by rincebrain
3 months ago
Yes, in theory.
But there's not a huge market (and therefore, FOSS dev time spent on it) for emulating AArch64 on x86 the way there is x86 on AArch64, so if your options are to build your own AArch64 emulation for x86 (or drop a fortune into an existing FOSS option), or building something based on AArch64 and using the existing x86 emulation implementations, one of these has much more predictable costs and outcomes today.
Sounds like a project for Valve to back then.
They could, but why?
If an ARM device both suits the goals and has lower risk, there's little upside other than forcing the project to exist.
And since there's very few pieces of AArch64-exclusive software that Valve is trying to support, that's not a goal that benefits the project.
(If I were guessing without doing much research, Switch emulators might be the largest investment of effort in open source on x86 systems running AArch64 things performantly, but that's certainly not a market segment Valve is targeting, so...)
To have flexibility and not being tied to CPU choice due to simply lacking software side. Besides, such kind of project would be beneficial to more scenarios than their immediate need.
They didn't need to back a bunch of projects they backed (radv / aco are a big example where you could claim there was redundancy so they weren't strictly necessary), but results paid off even to the point where AMD is dropping their amdvlk in favor of using radv/aco.
They didn't need to strictly speaking back zink either (OpenGL on Vulkan), but they decided to and it gives them a long term ability to have OpenGL even if native drivers will be gone, as well as an upside of bringing up OpenGL on any Vulkan available target out of the box.
It's just something in their style to do when there seems to be an obvious gap.
2 replies →