Thanks for your insight as always Mark. You work wonders!
Here's hoping Apple make things easier with the Tessellation side of things later on macOS this year.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Vulkan official for MacOS, iOS
- Thread starter Flint Ironstag
- Start date
- Sort by reaction score
Thanks for your insight as always Mark. You work wonders!
Here's hoping Apple make things easier with the Tessellation side of things later on macOS this year.
Agent 47's outstandingly smooth noggin is a clear indication that Hitman also makes heavy use of tesselation.
One more thanks for this post. Besides Apple PR there is a real life struggle whenever you play a AAA title on Mac and Apple is making it even harder those days.
How much it takes, how often it relies on only one developer, and how much are Linux and Mac gaming interconnected, you can read in Ryan Gordon interview
https://boilingsteam.com/icculus-ryan-gordon-tells-us-everything-part-1/
Quote from Brad Oliver (from a discussion with you…
)I admittedly seem to have been wrong about Agent 47's noggin, but I was sure that I had read that the Mac version of Hitman was delayed due to problems with making tessellation work (amongst others).
DiRT Rally's settings files mentions tessellation for water and clothes, so it seems to be using it, too.
Last edited:
Quote from Brad Oliver (from a discussion with you…
DiRT Rally's settings files mentions tessellation for water and clothes, so it seems to be using it, too.
Feral (main Mac porting house?!) waisted 2 years waiting for Metal 2 to be even technically possible (reasonable) to port Dirt Rally right in the time when it was on 80% sale on Steam.
What business sense that makes to anyone?
And I was just looking inside game folders of some of the latest Feral and Aspyr OpenGL ports (Grid Autosport, MW3) to see how many cached textures, special cases shaders etc. there are.
To be back on topic, this Moltenvk Kronos support is great but will go only as far as Metal can support or have even better solution to those special cases.
Otherwise this will only cut development costs for few Valve dx9 era titles.
Apple aren’t making it any harder than they ever have. In many ways with Metal they have made it easier, but the industry never stops moving forward and they were stupidly far behind.
Mac and Linux were close in the past but are likely to diverge in fortunes now. As they no longer share a common graphics API there is much less overlap.
That would be a truly ambitious timeline. I think we have a little bit more time than that before my concerns become immediate problems. It might irritate me for bit longer, but that’s not important in the grand scheme of things.
Mark, do you view the Metal tessellation pipeline as tailored to AX GPUs? I'm wondering, since I'm not aware of different tessellation pipelines in Vulkan that would depend on desktop vs mobile GPUs.
Apple merely justified their approach with a "clean sheet" argument, and implied they did it for the sake of simplicity (not simplicity of porting from DX, obviously).
Apple merely justified their approach with a "clean sheet" argument, and implied they did it for the sake of simplicity (not simplicity of porting from DX, obviously).
Exposing the DX hull/geometry/domain shader stages requires lots of shader compilation work to occur at draw call time on DX11/GL *or* pipeline construction time on Vulkan/DX12 (emphasis for clarity - it is one or the other and depends on the API which it is). All the vendors have to move some code between the different stages to suit their hardware to make it *appear* that these stages are independent when really they aren’t.
AMD, Intel and all mobile GPUs I am aware of internally require that the first stage of tessellation be dealt with separately - the vertex/hull stage that Apple require be implemented as compute - and for the data to be exported to VRAM for later consumption by subsequent stages. Nvidia’s hardware is a little bit cleverer but I don’t really understand the whys and wherefores.
In other APIs AMD and Intel can break a single draw call into small chunks that are processed using a small amount of VRAM/cache to do this vertex/hull work and then switch to consuming it in the “domain” shader stage. This means the developer doesn’t have to care about providing scratch buffers for the intermediate data that are large enough for the draw call. It *appears* just like the Nvidia card, only a bit slower.
Mobile GPUs *can’t* usually do that as they process ALL geometry before processing any pixels. So they need to store all the intermediate data for all draw calls for the duration of the render pass. That consumes a lot of memory but Khronos and Microsoft are looking for consistency and continuation of the API to enable developers - so the hardware vendors either fix the hardware, swallow the memory cost or don’t implement tessellation.
Apple didn’t want to do this as they design Metal with a philosophy of exposing all the costs and problems to developers, sometimes this puts them at odds with industry standards and norms. It suits Apple’s hardware and it functions adequately on AMD. The problem is that it was decision that didn’t reflect the potential future and I expressed that at the time. It closes off an avenue of rendering development to use fully GPU driven rendering where the GPU alone decides what to render and encodes all the necessary draw commands. Apple’s approach needs the CPU to know every detail of what’s going on to allocate temp buffers and separate the issuing of dispatch and draw calls when they are one draw call on all other APIs.
I'm not an expert, but I understand that Metal has lower overhead (i.e., can be faster) than openGL (or even directX 11), but misses some features, like geometry shaders. It's far behind DirectX 12 in terms of features, but it may be simpler to use, from what I heard.