> Tessellation enables games like The Witcher 3 to generate geometry. The M1 has hardware tessellation, but it is too limited for DirectX, Vulkan, or OpenGL. We must instead tessellate with arcane compute shaders
> Geometry shaders are an older, cruder method to generate geometry. Like tessellation, the M1 lacks geometry shader hardware so we emulate with compute.
Is this potentially a part of why Apple doesn't want to support Vulkan themselves? Because they don't want to implement common Vulkan features in hardware, which leads to less than ideal performance?
(I realize performance is still relatively fast in practice, which is awesome!)
> Is this potentially a part of why Apple doesn't want to support Vulkan? Because they don't want to implement common Vulkan features in hardware, which leads to less than ideal performance?
Yes, it's a big reason.
I tried to port the yuzu switch emulator to macos a few years ago, and you end up having to write compute shaders that emulate the geometry shaders to make that work.
Even fairly modern games like Mario Odyssey use geometry shaders.
Needless to say, I was not enough of a wizard to make this happen!
Are you talking about Vulkan or about geometry shaders? The later is simple: because geometry shaders are a badly designed feature that sucks on modern GPUs. Apple has designed Metal to only support things that are actually fast. Their solution for geometry generation is mesh shaders, which is a modern and scalable feature that actually works.
If you are talking about Vulkan, that is much more complicated. My guess is that they want to maintain their independence as hardware and software innovator. Hard to do that if you are locked into a design by committee API. Apple has had some bad experience with these things in the past (e.g. they donated OpenCL to Kronos only to see it sabotaged by Nvidia). Also, Apple wanted a lean and easy to learn GPU API for their platform, and Vulkan is neither.
While their stance can be annoying to both developers and users, I think it can be understood at some level. My feelings about Vulkan are mixed at best. I don't think it is a very good API, and I think it makes too many unnessesary compromises. Compare for example the VK_EXT_descriptor_buffer and Apple's argument buffers. Vulkan's approach is extremely convoluted — you are required to query descriptor sizes at runtime and perform manual offset computation. Apple's implementation is just 64-bit handles/pointers and memcpy, extremely lean and immediately understandable to anyone with basic C experience. I understand that Vulkan needs to support different types of hardware where these details can differ. However, I do not understand why they have to penalize developer experience in order to support some crazy hardware with 256-byte data descriptors.
I’m not a game programmer, so I just sort of watch all this with a slightly interested eye.
I honestly wonder how much the rallying around Vulkan is just that it is a) newer than OpenGL and b) not DirectX.
I understand it’s good to have a graphics API that isn’t owned by one company and is cross platform. But I get the impression that that’s kind of Vulkan‘s main strong suit. That technically there’s a lot of stuff people aren’t thrilled with, but it has points A and B above so that makes it their preference.
(This is only in regard to how it’s talked about, I’m not suggesting people stop using it or switch off it to thing)
Nothing stops them from providing their own API and Vulkan both. So your arguments only make sense for why they might want other API but they don't make sense on the part reasons for completely denying Vulkan support alongside it. There is no good reason for that and the apparent reason is lock-in.
Geometry shaders have almost always sucked in all fairness. I'm surprised a game newer than 2015 bothered with them. It's been pretty common knowledge that geometry shaders really only work better on Intel hardware (and I'm not sure how long that lasted).
Tessellation falling short is just classic Apple, though. Shows how much they prioritize games in their decision making, despite every other year deciding they need a AAA game to showcase their hardware.
(apologies for the crude answer. I would genuinely be interested in a technical perspective defending the decision. My only conclusion is that the kind of software their customers need, like art or editing, does not need that much tessellation).
Geometry shaders have long been disfavored by all ISVs , not just Apple. It’s just most include the software path.
If you’re using geometry shaders, you’re almost always going to get better performance with compute shaders and indirect draws or mesh shaders.
A lot of hardware vendors will handle them in software which tanks performance. Metal decided to do away with them rather than carry the baggage of something that all vendors agree is bad.
It takes up valuable die space for very little benefit.
Because they don't care. They've decided that Metal is The One True Way to write 3D-accelerated apps on macOS, so they only implement the things in hardware that Metal requires.
There are definitely some features omitted from Apple's GPU, but fairly early in the reverse engineering process, Alyssa Rosenzweig provided several examples of hardware features present in Apple's GPU that are not exposed by Metal: https://rosenzweig.io/blog/asahi-gpu-part-4.html
Maybe, but we got here because I asked "is it possible that Apple doesn't want to support Vulkan (in software) because they don't want to support the features it needs (in hardware)."
If the reason they don't support it in hardware is because they don't want to support it in software, then the logic gets a bit circular.
I'm interested in which came first, or if it's a little of both.
Vulkan very much is designed to give flexibility to hardware vendors. Where abstractions do paper over differences it's generally where it makes the abstraction cheap in runtime but you might take more code vs. less code but requiring a feature that would be otherwise optional (for example some of the complex pipeline manipulation Vs bindless)
Perhaps, but also geometry shaders are generally losing popularity and on their way out. Per google ai search result (for what it is worth):
Geometry shaders are generally considered less necessary in modern graphics pipelines due to the rise of more flexible and efficient alternatives like mesh shaders which can perform similar geometry manipulation tasks with often better performance and more streamlined workflows
We would still like the changes to be upstream but they may need more polish, and it spawned a conversation about the division of responsibilities between SPIRV-Cross and MoltenVK:
Apple not supporting Vulkan is a business decision. They wanted a lean and easy to learn API that they can quickly iterate upon, and they want you to optimize for their hardware. Vulkan does not cater to either of these goals.
Interestingly, Apple was on the list of the initial Vulkan backers — but they pulled out at some point before the first version was released. I suppose they saw the API moving in the direction they were not interested in. So far, their strategy has been a mixed bag. They failed to attract substantial developer interest, at the same time they delivered what I consider to be the best general-purpose GPU API around.
Regarding programmable tessellation, Apple's approach is mesh shaders. As far as I am aware, they are the only platform that offers standard mesh shader functionality across all devices.
That might be an excuse, but that's hardly a reason. They are simply extreme lock-in proponents and don't want to support cross platform graphics API. That's the real reason.
They don't seem to care. I'm sure that will bite them in the long term, but for now they are very intent on complete NIH and lock-in anywhere they can push it.
> Geometry shaders are an older, cruder method to generate geometry. Like tessellation, the M1 lacks geometry shader hardware so we emulate with compute.
Is this potentially a part of why Apple doesn't want to support Vulkan themselves? Because they don't want to implement common Vulkan features in hardware, which leads to less than ideal performance?
(I realize performance is still relatively fast in practice, which is awesome!)