The irony is that volunteers are going to get CS2 running on Mac hardware before apple purely by reverse engineering the Apple silicon GPUs for Asahi Linux.
Apple really thought they could do what AMD and 3DFX failed to do and randomly push a competitor to Vulkan/OpenGL that only supports a handful of hardware SKUs that aren’t dominant in the market anyway.
Metal is incredibly successful… Just not on Mac. It’s the graphics API that drives the iPhone and iPad.
It seems like they’re worrying about Macs again, but when Metal was released the focus was iOS and it did bring significant performance improvements to that platform.
We can say whatever we want about mobile games, but in numbers, they’re dominant and the App Store is one of Apple’s biggest revenue sources.
I don’t disagree - I don’t own Apple products, and I very much would prefer if all games also dropped DirectX.
But my point is that Metal didn’t fail, and it’s not “used in a minority of devices” and Apple isn’t “crazy for thinking they would succeed with a new graphics API for games” because by all relevant metrics, dominance over mobile gaming is much more important.
Games “tend” to dominate a single, or very few cores. With modern PCs having 4 or more. You can push an isa-translator off on to a low power core. Since it won’t be a constant, heavy lifting task. Then push the translated instructions through your high performance cores. Your biggest penalty on that will generally be a small bit of latency.
Your biggest hit will likely come from having to wrap graphics APIs. But again, that hit is generally what it takes to do the same under Linux with wine/proton.
But as long as your CPUs can push the instructions fast enough. Your data bus can manage the data transfers in a timely manner. And your graphics subsystem can handle the load. It’s a doable task.
It’s very similar to emulating retro systems in a number of ways.
The irony is that volunteers are going to get CS2 running on Mac hardware before apple purely by reverse engineering the Apple silicon GPUs for Asahi Linux.
Apple really thought they could do what AMD and 3DFX failed to do and randomly push a competitor to Vulkan/OpenGL that only supports a handful of hardware SKUs that aren’t dominant in the market anyway.
Metal is incredibly successful… Just not on Mac. It’s the graphics API that drives the iPhone and iPad.
It seems like they’re worrying about Macs again, but when Metal was released the focus was iOS and it did bring significant performance improvements to that platform.
We can say whatever we want about mobile games, but in numbers, they’re dominant and the App Store is one of Apple’s biggest revenue sources.
Every 3D game on iOS is Metal.
Sure, metal offered significant improvements over opengl when it released, but now that vulkan exists apple doesn’t have any more excuses.
I don’t disagree - I don’t own Apple products, and I very much would prefer if all games also dropped DirectX.
But my point is that Metal didn’t fail, and it’s not “used in a minority of devices” and Apple isn’t “crazy for thinking they would succeed with a new graphics API for games” because by all relevant metrics, dominance over mobile gaming is much more important.
Really? x86 games emulated usably on ARM?
Games “tend” to dominate a single, or very few cores. With modern PCs having 4 or more. You can push an isa-translator off on to a low power core. Since it won’t be a constant, heavy lifting task. Then push the translated instructions through your high performance cores. Your biggest penalty on that will generally be a small bit of latency.
Your biggest hit will likely come from having to wrap graphics APIs. But again, that hit is generally what it takes to do the same under Linux with wine/proton.
But as long as your CPUs can push the instructions fast enough. Your data bus can manage the data transfers in a timely manner. And your graphics subsystem can handle the load. It’s a doable task.
It’s very similar to emulating retro systems in a number of ways.
Source 1 engine games like half life are running atm via box_x86