Can someone explain what "In general, Metal does tessellation differently, and is missing geometry shaders and transform feedback." mean?
In a nutshell:
- Tesselation is the GPU pipeline for generating geometric primitives from parametric surfaces (e.g. Bezier patches). Tessellation API is usually organised into three stages (programmable tessellation control shader, fixed-function tessellator proper and programmable tessellation evaluation shader). DirectX calls them differently, but the purpose is the same. These stages are there for historic reasons, it was implemented this way the first time and APIs kind of kept this schema to be backwards compatible. Now, Apple in their usual fashion decided that the "old way" is too cumbersome and have rolled their own approach to tessellation which relies on regular old compute shaders and vertex shaders (no special shader stages with their own names). Again, the end result is the same, and Apple's approach is arguably more sensible (as it is less idiosyncratic), but it does create difficulties when porting software from other APIs.
- Geometry shaders are special shader stages that can generate geometry for further processing. Their introduction is now generally regarded as a design mistake, as they are difficult to parallelise and therefore perform poorly (modern DX12 introduced mesh shaders to replace most advanced applications of geometry shaders). Apple never introduced geometry shaders in Metal — again, a "correct" decision (since geometry shaders suck), but one that makes porting some software that uses these shaders more cumbersome. Technically, Metal does not need these shaders as anything you would use them for can be easily done either in the vertex shader or compute shaders.
- Transform feedback is functionality for capturing transformed (after common shader stages) vertex data for further processing. I see it mentioned here and there that Metal does not support transform feedback, but it is not really true. Metal trivially supports this functionality via the regular pipeline — vertex shaders in Metal can write to memory. So if you want to store the transformed vertex data all you need is a vertex shader that saves the data to a buffer.
After reading this I think apple should bring out a new metal version.
By All Blogs | CrossOver support for DirectX 12 on Linux and Mac.
www.codeweavers.com
Quick note on the "500000 resources per argument buffer" limitation vs. DX12 "one million" — it's not as straightforward. DX12 limits refer to max number of descriptors (entries that described resource binding of some sorts). Metal limits refer to the max number of available texture or buffer resources. My guess is that DX12 applications will use more descriptors on average, since they have to access any kind of data via a descriptor — this is not the case for Metal, where directly provided data and things like textures can be bound within the same argument buffer. The differences in how APIs are approaching resource binding makes it difficult to compare.
I think that one can get very far by simply implementing these things without any regard to differences in API limits. It is highly unlikely that any shipping game actually makes use of DX12 limits (one million descriptors is a LOT), and if it does, well, there is not much one can do anyway, so one just has to crash.
