Vulkan official for MacOS, iOS

[JordanNZ]

UE4 uses geometry shaders for a range of volumetric effects and the workarounds for Metal have non-zero performance costs and are hacks that are intermittently a maintenance nightmare. Unfortunately we *need* to do things this way as it is the only way to leverage all the dedicated silicon on modern desktop GPUs. Compute solutions for this tend to be more complicated and less efficient unless you build a heck of a lot of infrastructure - I think only Frostbite is really at that level.

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.

 

[jeanlain]

Let's hope macOS game developers have some influence on Apple. I'm sure all those issues and concerns have been reported. We'll see at next WWDC when Apple (hopefully) announces the new Mac Pros and official eGPU solutions.

 

[Janichsan]

Which games from Feral use Metal tessellation?

From my former colleagues at Feral I believe both ‘Deus Ex Mankind Divided’ and ‘Rise of the Tomb Raider’ use and require tessellation.

Agent 47's outstandingly smooth noggin is a clear indication that Hitman also makes heavy use of tesselation.

 

[jeanlain]

I think I read that the latest Hitman doesn't use tessellation (as opposed to the previous one).
I wonder about the DiRT and F1 games.

 

[BarbaricCo]

From my former colleagues at Feral I believe both ‘Deus Ex Mankind Divided’ and ‘Rise of the Tomb Raider’ use and require tessellation.



If you’d ever worked on a modern game engine you would know that these features are fully embedded and perform few but critical functions. They are impossible to remove from the API standards now.

UE4 uses geometry shaders for a range of volumetric effects and the workarounds for Metal have non-zero performance costs and are hacks that are intermittently a maintenance nightmare. Unfortunately we *need* to do things this way as it is the only way to leverage all the dedicated silicon on modern desktop GPUs. Compute solutions for this tend to be more complicated and less efficient unless you build a heck of a lot of infrastructure - I think only Frostbite is really at that level.

In future when we make use of the DrawIndirect, MultiDrawIndirect and ExecuteIndirect functions it will not be possible to suppprt Metal tessellation as it stands today. That’s because Apple’s approach require that the CPU allocate a separate temporary buffer for each tessellated draw call, which you just don’t when using Indirect functions as in that case the draw command data is known only to the GPU. There is no way to fix this that won’t cripple performance or result in some objects just not rendering at all or consuming many times the video memory of PC, any of which would be unacceptable.

I’ll also admit that this is a change in stance for me, the growing use of DrawIndirect/MultiDrawIndirect/ExecuteIndirect has shown me the future. They really highlight problems that I hadn’t really been thinking about before.

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/

 

[Janichsan]

I think I read that the latest Hitman doesn't use tessellation (as opposed to the previous one).
I wonder about the DiRT and F1 games.

Quote from Brad Oliver (from a discussion with you… )

FWIW, Hitman 2016 shipped using Metal's compute tessellation - it's used for rendering the water.

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.

 

[jeanlain]

Nice find. ^^

 

[BarbaricCo]

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.

 

[marksatt]

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/

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.

Here's hoping Apple make things easier with the Tessellation side of things later on macOS this year.

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.

 

[jeanlain]

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).

 

[marksatt]

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).

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.

 

[beepp]

Without going into technical details can somebody inform that Metal 2 now on pair with latest OpenGL and DirectX?

 

[jeanlain]

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.